So, Mary-Jo Foley calls VFP the "Rodney Dangerfield" child of Microsoft's solution and we wonder why there are mixed messages.
Steve Black emailed me this post where the supposed "Head of information technology" at an Indian company had to upgrade because "the software was not scalable as it had been developed on FoxPro".
Excuse me? The older software was probably not scalable because this guy, or the person who worked there before him, who had originally commissioned the software likely wrote it not to scalable. Yes, it was written in FoxPro - but it could likely have been written in Visual Basic.Net or Delphi or anything.
Applications are not inherently "not scalable" because of the platform but more because of the design.
Near the end of the article , the comment "Compared to legacy systems, which needed to be changed every six or seven years, SAP solutions are expected to prove effective for 20 to 25 years and beyond." - - "are expected to"???
SAP has only been in business since 1972 and while they have commendably only had 3 core versions but even so, R3 was only released in 1990 and I'm sure there have been upgrades since then. And is SAP written in the same language as it was back in 1979? I don't THINK so!
But why is it successful ? Because it was designed properly. (and I'm not an SAP expert - so I'm sure there are those who would say otherwise as well)
I've seen this before in lots of organizations. It sounds to me like the "head of IT" was likely someone who designed poorly written systems in the past, recognized it, became a manager who preferred "third party" vendors who would have to do the real scalable design work and then blamed their past failures on the product. Have you ever run across those kinds of people before?
By contrast, some businesses have been running the same FoxPro applications for years. One Canadian government agency refused to support FoxPro - their IT department thought that Paradox would be the next big thing - in the early 90's , even though their survey applications and many internal office systems were running with FoxPro. Their IT department changed and went to Visual Basic and SQL Server solutions. While the SQL database may have been fast, their programmers designed the new survey applications poorly and as a result, they went back to the ten-year old FoxPo program which wasn't just reliable but faster as well.
Craig Bailey posted this about the new MS certified Architect - this sounds like something that every head of IT should have BEFORE spreading mis-information.
General programming rule: It's not about the product - it's about the DESIGN!!!
I even recall hearing someone who worked at Microsoft say exactly the same thing. Internal systems at Microsoft weren't always written to be scalable and thus had to be re-architected.
Heck! I'm in the middle of re-architecting an older application to be more scalable and run under SQL Server. The older application used indices and filters to show information to a user. Could it run with a million records? sure! Should it? No! So the issue is one of how do you redesign it? In VFP or under another language?
In the most recent FoxShow (to be posted today I hope), John Petersen noted how he was interested to see how the arguments for FoxPro actually worked in a business meeting.
After reading this article and the mis-information spread around through it and other journals and by otherwise 'well-meaning" "IT experts", you can start to see a pattern. It isn't bad marketing that FoxPro is up against - it's ignorance, plain and simple.
How do you fight ignorance? By making BETTER applications (yes, I've said this before)
Some have noted that Ruby on Rails doesn't follow along the path of traditionally designed n-tier applications, choosing speed over architecture. Uh, tell that to 37Signals, the group behind Basecamp. Not sure how many users they have using it, but sure feels like a scalable application to me.
So once again, let me repeat: It's not about the product - it's about the DESIGN!!!
Steve Black emailed me this post where the supposed "Head of information technology" at an Indian company had to upgrade because "the software was not scalable as it had been developed on FoxPro".
Excuse me? The older software was probably not scalable because this guy, or the person who worked there before him, who had originally commissioned the software likely wrote it not to scalable. Yes, it was written in FoxPro - but it could likely have been written in Visual Basic.Net or Delphi or anything.
Applications are not inherently "not scalable" because of the platform but more because of the design.
Near the end of the article , the comment "Compared to legacy systems, which needed to be changed every six or seven years, SAP solutions are expected to prove effective for 20 to 25 years and beyond." - - "are expected to"???
SAP has only been in business since 1972 and while they have commendably only had 3 core versions but even so, R3 was only released in 1990 and I'm sure there have been upgrades since then. And is SAP written in the same language as it was back in 1979? I don't THINK so!
But why is it successful ? Because it was designed properly. (and I'm not an SAP expert - so I'm sure there are those who would say otherwise as well)
I've seen this before in lots of organizations. It sounds to me like the "head of IT" was likely someone who designed poorly written systems in the past, recognized it, became a manager who preferred "third party" vendors who would have to do the real scalable design work and then blamed their past failures on the product. Have you ever run across those kinds of people before?
By contrast, some businesses have been running the same FoxPro applications for years. One Canadian government agency refused to support FoxPro - their IT department thought that Paradox would be the next big thing - in the early 90's , even though their survey applications and many internal office systems were running with FoxPro. Their IT department changed and went to Visual Basic and SQL Server solutions. While the SQL database may have been fast, their programmers designed the new survey applications poorly and as a result, they went back to the ten-year old FoxPo program which wasn't just reliable but faster as well.
Craig Bailey posted this about the new MS certified Architect - this sounds like something that every head of IT should have BEFORE spreading mis-information.
General programming rule: It's not about the product - it's about the DESIGN!!!
I even recall hearing someone who worked at Microsoft say exactly the same thing. Internal systems at Microsoft weren't always written to be scalable and thus had to be re-architected.
Heck! I'm in the middle of re-architecting an older application to be more scalable and run under SQL Server. The older application used indices and filters to show information to a user. Could it run with a million records? sure! Should it? No! So the issue is one of how do you redesign it? In VFP or under another language?
In the most recent FoxShow (to be posted today I hope), John Petersen noted how he was interested to see how the arguments for FoxPro actually worked in a business meeting.
After reading this article and the mis-information spread around through it and other journals and by otherwise 'well-meaning" "IT experts", you can start to see a pattern. It isn't bad marketing that FoxPro is up against - it's ignorance, plain and simple.
How do you fight ignorance? By making BETTER applications (yes, I've said this before)
Some have noted that Ruby on Rails doesn't follow along the path of traditionally designed n-tier applications, choosing speed over architecture. Uh, tell that to 37Signals, the group behind Basecamp. Not sure how many users they have using it, but sure feels like a scalable application to me.
So once again, let me repeat: It's not about the product - it's about the DESIGN!!!
Comments