Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
New case study in MSDN Flash - part 2
Message
General information
Forum:
Visual FoxPro
Category:
Other
Title:
New case study in MSDN Flash - part 2
Miscellaneous
Thread ID:
00859732
Message ID:
00859732
Views:
78
Ken,
How does one go about having a "Case Study" withdrawn from publication or at least seriously re-written for a modicum of clarity and sense???

Despite your successful interventions the article is still very unclear and suggests that the writer (A staff member of CDS Inc. as I understand) really doesn't know what he's talking about and it remains a clear slap in the face to Visual FoxPro.

Following I will attempt to show just how bad the article remains, even in its present form...

  • Both the article preamble and the side-bar ("Solution Overview") state that the subject application is "stand-alone". I assume this means that they have sold 41 separate product units to each of the associations using the product and that each user is running their copies of the application independently of each other. Is that the case or am I misinterpreting something here?
    Assuming that my interpretation is correct I wonder what the purpose is of mentioning, in the "Situation" section in the body of the article "The states average approximately 15 users. We process over 4 million transactions per year.? That would really have no bearing at all on this article, would it? And my caclulation works out to a whopping average of 22 transactions per day per user in a 300 business-day year. Or 13,530 transactions daily.

  • In the side-bar is the statement "Unfortunately, the stand-alone application could not easily be web enabled.". What would be a reasonable reason for this?... A reader knowing no better would immediately surmise that no Visual FoxPro application can be "web enabled". What version of Visual FoxPro is CDS Inc. using that makes this a true statement?... Or is it possible that it is not a true statement? Or is it possible that CDS wanted an excuse to jump into .NET so they fabricated this line of 'logic'? (I see in the side-bar that they are using VFP 6.0 and if this is accurate (hard to say, given that the sub-title mentions SQL Server 2000 but the side-bar states SQL Server 7.0) then it truly is a bald-faced lie). Don't you think that a "case study", not to mention MS' customers generally, deserve the truth? This doesn't sound like any kind of 'truth'!
  • The second paragraph under "Situation" says "AM4 was originally written in Microsoft® Visual FoxPro® database development system.". This isn't even a valid sentence and suggests that the writer has no real understanding of what Visual FoxPro really is. Surely it would have been stated differently if the writer did know what Visual FoxPro in fact is! Things start here to smell a lot like someone who wants to justify a move to .NET rather than someone who 'needs' to do the migration (neglecting the side-bar issue mentioned above, which only add more odour)!
  • The two sentences following the citation above only adds more confusion. They read as follows: "While still using Visual FoxPro as a key part of the solution, CDS moved their DBF file based data to Microsoft SQL Server™. "We have ported most of our clients over to SQL Server, there are a handful still using FoxPro tables," said Greg Robinson...". Someone who doesn't know better would read into this that (really) only a handful (of clients) are still using the original VFP system despite the starting words ("While still using Visual FoxPro as a key part of the solution"). There needs to be some clarification that Visual FoxPro allowed them to do this because of its complete flexibility regarding data sources it can process. Furthermore, this reads like the "porting" was a part of the article's subject 'solution' while it seems in fact that this was done prior to embarking on the project that is the subject of the article. And in either case it strongly suggests that applications using 'DBF file based data' cannot be web enabled or participate in web services. Stronger smell now!
  • The first 3 sentences of the "Solution" section, let's agree, speaks the truth - that CDS wanted to migrate to the latest Microsoft technologies. So what was the purpose of all of the words up until now in the article?... there can be only one purpose, and that is to denigrate Visual FoxPro.
  • Does the writer really believe what he says when he says "...single developer can achieve in a short time..." and then immediately reports a 48-72 man-month effort? this is productivity?
  • In the "Benefits" section, what is the bit about "...along with VB 6 COM DLLs."?!?! A reader only has confirmed by this the prior implication that NO VFP application can be web enabled or participate in web services! The smell is now pungent! I trust marketers only as far as I can throw them, so I believe the whole construction of this article is deliberate and aimed squarely at denigrating VFP!
  • The next statement in the article proves my suspicion beyond any shadow of a doubt: "...and would have left us with our original code, based on a dated technology.". This strongly suggests that they now have no 'dated code' in their new system (and by implication NO VFP code) and also says outright that VFP technology is "dated". That VFP is still under development is not mentioned. That VFP can be web enabled and participate in web services remains untold. The STINK is now obvious!!!
  • Two paragraphs from the end of the article we learn that CDS is only "Midway through the AM for .NET development process..."!!! What the hell is this doing in a case study at all????? Is MS so bereft of .NET implementations that they're now publishing wannabe 'case studies' that may yet fail???
  • If I was considering a migration of my working application to .NET (whatever the language of the original) the sentence "By enforcing controls that ensure updates are accurately posted to the AM4 database..." would cause me GREAT CONSTERNATION... sounds like I have to do things way differently than I currently do when I use .NET for data updating!
  • Finally, in the side-bar the "benefits" listed were hardly demonstrated by the article... 'faster time to market' seems the antithesis of what was described in the article... 'performance' was not even mentioned in the article... 'scalability' is hardly needed given the transaction rates quoted in the article... 'reliability' is a hard sell on a project that is half completed... 'full Windows/Office integration' was not at all mentioned in the article!!!


  • So, Ken, the article is worthy of quarter-slicing for use in the throne room as it is currently written and should be a huge embarrassment to Microsoft generally. It deserves immediate withdrawl or a complete rewrite for accuracy, relevance and TRUTH!

    Jim
    Next
    Reply
    Map
    View

    Click here to load this message in the networking platform