those of you who know me well will already know that i have been saying since the first views of .net went public that my opinion is that .net will be the straw that breaks the camel’s back. in other words, i think that microsoft has got the whole .net thing so badly wrong that, in the long run, it could actually bring the company down. interestingly craig bailey has posted something only the other day that takes a different slant on the question but which, i think, makes some extremely telling points. check out his article right here:

http://craigbailey.blogspot.com/2005/07/net-return-on-complexity-roc.html

but back to my thoughts. why do i think that microsoft, a notoriously good marketing company, has got this one wrong? well here, in a single sentence, is my reason.

there is simply no defensible case for switching from an existing development platform to .net!

now let me expand on this a little. first i must stress that i am totally impressed by and thoroughly in favor of asp .net! this is the tool for which web developers have been longing since commercial internet applications first began to be constructed. it is long overdue, and only looks like it is going to get better with time. so i am totally behind the asp .net initiative. but, alas, as for the rest of .net, it is ill-conceived, poorly implemented and adds little or no real value to the existing development tools and environments. consider this from the view of an existing application developer – why should such a person change their development environment and tools? seems to me that there are three “imperatives” which drive such a change:

·         technical imperative (the most important!)

·         infrastructure imperative (often a major limitation)

·         business imperative (the least important!)

let’s examine each in turn.

technical imperative

basically this states that the new environment will permit you to tackle tasks that, in your current development environment you simply cannot do. this is why i am so enthused about asp .net - it definitely has the technical imperative going for it.

however, for the rest of .net the case is totally different! what can you do in .net that you cannot already do in your current development environment?

note that i am not saying that .net cannot do some things better – of course it can (but by the same token it also does some things worse!!!). the key question here is what it can do that you cannot do with your current development tools? if there is something (and i don’t know what your chosen development environment is) then the second question is “does it matter?”.

my take on this is that organizations and people choose tools that are appropriate to their needs. (if it helps to use an analogy consider this: does an electrician really need a automobile hub-puller? probably not, but an auto-mechanic…?). by definition, therefore, anyone already developing software has the appropriate tools at hand and really does not need anything else! so unless there is an overriding technical issue that has hampered them in the past and which .net allows them to solve, they have no reason to switch.

my problem with .net (in this context) is that i do not see anything that could possibly be construed as “new capabilities”. all i see is different ways of doing things that we can do already. therefore it fails on the most important of the three imperatives.

infrastructure imperative

this states that an organization has been limited in its choice of development environment by the need to operate and support an existing hardware infrastructure. the imperative comes into play when, for some other reason than software development, that infrastructure is changed or upgraded so that environments that could not hitherto be supported can now be used. in other words, the driver here is the fact that something external to the software process has driven the change.

the problem that confronts .net is that its adoption typically requires an infrastructure change (i.e. hardware upgrade). so instead of being a concomitant option that becomes available when the change occurs for other (usually economic) reasons it’s adoption necessitates the change and therefore has direct long term cost implications.

when taken in conjunction with the technical imperative above the combination is potentially ruinous.

business imperative

now this is the drive on which microsoft has, to date, based the entire .net strategy (and in fact the entire corporate farm). this imperative, simply put, relies on fear and (technical) ignorance. the basis for adopting .net has nothing whatever to do with it’s technical merits or requirements but it is done simply because of the perception that “competitors” are doing so!

it is significant that most of microsoft’s efforts at marketing .net are not directed at technical personnel but at “management” – particularly “senior management”. this reflects, i believe, the fact that they realized early on that they could not actually meet either of the imperatives for technology or infrastructure and that the only way to promote widespread adoption of their flagship new product was to rely on this approach.

to date the take up has (reportedly) been “disappointing” and “slower than we had hoped”. the main adopters seem, on the whole, to have been large organizations where the non-technical approach works best. in smaller organizations, where decision makers are closer to the actual technology, i suspect that the take-up has been far less than most of us even realize.

how can .net hurt microsoft?

the key question is why did microsoft bother with .net? i believe that the answer lies in the business model for the corporation as a whole. for many years microsoft relied on the ‘upgrade’ model for their revenue. a new operating system was produced every two to three years and people rushed out in droves to buy it (remember the launch of windows 95?). microsoft office was (and still is) the best selling office package. upgrades came out and people upgraded. it has been estimated that office upgrades alone accounted for well over half (and i have seen estimates as high as 80%) of microsoft’s revenue in the late 1990’s.

the problem with this model is, of course, that it relies on people (and organizations) continuing to upgrade their software. as products reach maturity there is a limit to the number of ‘necessary’ new features that people will be willing to pay for – either in the operating system, or in the applications that they use. this was, i am sure, well understood by microsoft who had to be aware that there was going to come a time when people simply would not bother to upgrade any more. latterly of course, the rise of the open source initiatives has threatened both the office application and even microsoft’s flagship database sql server (which has not even been updated for 5 years now!) – why else the scramble to release first “msde” and now “sql server 2005 express”?

(just for the record, i am writing this in word 2000 running on a windows 2000 operating system! even though i have windows xp, windows 2003, office xp and office 2003, there is nothing new in any of them that i actually need. not only did i have some compatibility issues (especially powerpoint) when i tried newer versions, but i am already both familiar and comfortable with the “2000” versions – so why bother to upgrade?)

so where could microsoft turn for a significant new source of revenue? the answer they chose to adopt was, of course, to develop a comprehensive software development environment that would require investment to adopt and which, once adopted, would not be easy to get out of. we are looking at the result in .net!

of course .net is still in its infancy – the next release (whidbey) promises more and newer things but, significantly, makes no commitment to maintain backward compatibility with the current version of things. why? the official answer is so as not to constrain the development of the framework and the tools. the reality is, i suspect, that as with most new things the first versions were simply wrong. now they have to be fixed and correcting those fundamental flaws whilst maintaining backward compatibility has proven to be impossible (else, presumably, they would be trumpeting the fact!)

in the real world i believe that most software development is still done by small organizations (often only one or two developers) and unless microsoft can convince this sector of development world in general to adopt .net i do not see where the revenue to replace the ever decreasing stream of upgrade funds will come from.

this is why i think that, in the medium to long term, microsoft could be seriously hurt by their commitment to .net to the exclusion of almost every other product in their range! i hope the crash won’t be too disastrous because microsoft have been, on the whole, good for the industry. however, i still believe that the developer world is actually smarter than people at microsoft give them credit for and that microsoft are heading for a crash that will arrive sooner rather than later.

 

31 Responses to Whither .NET?

  • Steven Black says:

    Amen, brother. I’d just like to add that there is little doubt that .NET (as a whole) and .NET (its individual components, like the CLR, supporting integrated infrastructures like ASP.NET, and its languages like C# and VB.NET) will *eventually* reach a mind-share commensurate with its merits. Based on the their current vaulted and over-hyped position, this transition alone qualifies as a crash, as you describe it.

    <p comment="I hope this P tag works">For Microsoft, this inevitable crash to technical and practical reality will be damaging to the extent that their credibility and their pretenses of technical wisdom are involved. I can see far rosier outcomes for Microsoft if they become more forthcoming, and encourage their sycophantic mouthpieces to be more forthcoming, about the technical and functional risks aspects that .NET represents.

    <p comment="I hope this P tag works">I think everyone would be well advised to consider what Hal Varian has to say in his seminal book titled "Information Rules", which is really all about the lock-in that you obliquely refer to above.

  • Andy Kramek says:

    Thanks for the feedback Steve. I really appreciate your view (I haven’t read Hal Varian’s book – I need to do so!)

    But somehow I doubt that Microsoft will ever reduce their hyperbole – in fact the evidence is rather to the contrary. The more appaent that it becomes that the .NET results are disappointing, the more their efforts seem to be focused on extending the marketing campaign. It’s as if they think that if they repeat the message often enough, people will begin to believe it (a not unreasonable point of view given Human history in general).

  • Colin says:

    >> This is why I am so enthused about ASP .NET – it definitely

    >> has the technical imperative going for it.

    >>

    >> However, for the rest of .NET the case is totally different!

    >> What can you do in .NET that you cannot already do in

    >> your current development environment?

    Re-use some of that cool business logic I wrote for my ASP.NET app.

    Well, you asked.

  • Dave Bernard says:

    Hear, hear, Andy!

    Where, in the past, we waited breathlessly for the next version of our tool of choice to be rolled out, we now fret about absorbing large learning curves (and costs, if you’re a business owner) just to get to the next stage of a software tool vendor’s offering. In fact, we are probably still trying to fully absorb the version in which we’re working! The business world is much more savvy (and suspicious) of vendor’s hyperbolic claims, due to their experience in the dot-bomb era. You have to make the business case.

    Thus, as you said,

    <i>There is simply no defensible case for switching from an existing development platform to .NET!</i>

    Business has taken back the reins. They are no longer demanding whiz-bang features; they just want it to work, for once, and they want it on time and under budget, just like any other business project. They no longer see software as magic, but as an important business tool. They want mature, robust development environments that deliver highly-predictable results.

    They want to implement an efficient division of labor to handle the work, too. The increasing use of offshore (read: commodotized) resources means that businesses are quite satisfied to apply good, reliable software development tools and processes in order to meet business needs at a reasonable cost. This also clearly demonstrates that the rate of change in the software development paradigm (that business can absorb) is slowing.

    In my mind, there are no technical problems, only business problems. For many of us, .NET not only doesn’t solve any business problems, but, in fact, creates new ones! .NET is unproven, immature, slow and missing many features that many of us are used to in day-to-day development. Microsoft cannot even put out back-to-back versions that are compatible with each other. They managed to leave out COM Interop in the Compact .NET Framework, instantly nullifying a great body of work that would otherwise be easy to port to the handheld environment. The more I look at .NET, as I have since 2001, the more turned off I get. Microsoft’s attempt to be all things to all people manages to deliver fewer things to all people.

    Microsoft has made a big gamble in attempting to lock in the next generation of developers. I’ve been coding AJAX-style for quite some time and don’t see any business reason to switch; interesting to see that Microsoft is somewhat hedging their bets with ATLAS, in that regard. For me, even that would be a lateral move; all cost, no benefit.

  • Anonymous says:

    "The problem that confronts .NET is that its adoption typically REQUIRES an infrastructure change (i.e. hardware upgrade)"

    That was the .NET "synergy" — .NET forcing hardware upgrades allowing more .NET into the OS, then forcing hardware upgrades, forcing more .NET, etc. That cycle never got started (anyone remember MSFT stating unequivocally that .NET wouldn’t run on Win98?), so by that reason alone .NET is a bust.

    "The reality is, I suspect, that as with most new things the first versions were simply wrong. Now they have to be fixed and correcting those fundamental flaws whilst maintaining backward compatibility has proven to be impossible."

    …but Microsoft was loudly crowing the "fact" that companies were throwing out their mission critical business applications to rewrite them in beta versions of .NET 1.0. You mean to tell me that the DataGrid wasn’t revolutionary???? But Microsoft repeatedly said so!

    MSFT has lost tons of credibility. That’s why you see a lot of trumped up "studies" purporting that MSFT products are better than this, that or the other. It will take years to earn back the developer and managerial trust, if ever.

  • Welcome Back Andy!

    I couldn’t agree more with you.

  • Tore Bleken says:

    Well said, Andy, I couldn’t have said it better myself. I have considered .NET for many years, since I always find it necessary to keep an open mind. So far I have seen absolutely no reason at all to switch since I am able to do everything I need with my current tools, VFP + WWC.

    Another thing is that I got a terrible feeling against .NET the first time I got it thrown into my face, more or less. During the Advisor VFP devCon in Miami some years ago, the whole agenda was chenged and turned into a huge .NET propaganda show. I felt totally robbed, if it wasn’t for the nice beaches in Miami, I would have sued Advisor magazine for all my costs.

  • Claude Fox says:

    No need to develo entire web apps in ASP.NET either. If you’re more comfortable in VFP then just create a vfp mtdll and just call it from ASP.NET or ASP. IOW, VFP can continue to be used for web dev too! See ActiveVFP.

  • Anonymous says:

    Hey moron! Don’t censor the replies.

  • Andy Kramek says:

    John Doe: If you can’t be civil, please don’t clutter up my blog.

    Now what are you talking about? What replies have been censored, by whom and when? I have no control over the comments posted here and certainly cannot edit or censor them in any way.

    (By the way you may choose to be anynoymous but your IP Address is still sent to me – so, Hello in Montreal!)

  • Anonymous says:

    Regarding the comment by John Doe, I’m wondering if he ran into the same thing I ran into. I made a comment that should have appeared at about the #3 spot, but it never showed up. I didn’t get a confirmation or an error – it just went to some other page after I clicked submit and I figured the comment would show up eventually. It never did and I didn’t bother to re-post it. But more specifically, he probably made a negative comment trashing your posting and supporting .NET and when it didn’t show up he figured you were censoring.

  • Anonymous says:

    Great article but Microsoft will win in the end. By slowly killing off support for VB6 and focusing their marketing dollars on .NET. Microsoft will force developers either to move to a .NET language or move to a different development platform.

    Chances are that most developers will in the end just tag along with Microsoft for the ride.

  • Re russel: I too noticed a similar behavior… it happens when you do not enter the correct HIP code. Unfortunatly, I can not remove the HIP check from the weblog site as I receive about 300 spam injection requests in the comments area every hour…

  • Andy Kramek says:

    Re Russell. I am sure you are correct. But as Eric pointed out this is not censorship – by me or anyone else but is the sad necessity for any web log these days.

    I resent the assumption, the implication and the tone of the comment. Especially when the author does not even have the honesty to sign their own name.

  • Craig Bailey says:

    Hi Andy,

    Your post is very interesting reading. You mention 3 areas that resonate strongly with me:

    1. Business imperative – this is where I am feeling the pressure most intensely in our business – as you say, senior management has been the target of most of the marketing by Microsoft (and well done to Microsoft for identifying this key area). The result is that often technology decisions are not being made on technology grounds but on marketing grounds.

    2. ‘Software development is done by small organisations’ – this is indeed an interesting observation. If this is the case (and I suspect you are right) then perhaps this is a market Microsoft has the potential to reclaim through re-positioning of tools like VFP (as opposed to .Net which seems to be focussed more and more at the enterprise level).

    3. Following on from this, the decisions software managers need to make are no longer confined to choosing ‘the best tool for the job’ but now need to encompass market sentiment and client insecurities. The successful software companies will be the ones best able to negotiate this path.

    Thanks for a stimulating read.

  • Andy Kramek says:

    Re: Craig Bailey’s comments:

    As I said, it was your article that prompted me to set my own thoughts out in a (hopefully) logical format. So you certainly provoked my thought processes.

    "The result is that often technology decisions are not being made on technology grounds but on marketing grounds"

    This is exactly what I am seeing in the real world too – and it is a bad, and I believe, a potentially hazardous thing. In the long run it can only lead to more and more failed projects – with less and less confidence in the tools! This alone could cause the bursting of the .NET bubble to which you referred!

  • Andy Kramek says:

    Don Sullivan, Director of IT for the Division of Nursing at the Cleveland Clinic sent me the following comment on this entry. At his request I post it in its entirety:

    It has long been my opinion that Microsoft has been dragging us around on a journey through as many versions of OS, dev tools, office products, and hype as we can stomach. Their mantra “Do More With Less” about Windows Server 2003 was aimed right at business justification. I think MS began to realize that programmers can’t absorb as much hype as business users, so the whole .NOT strategy has been a trickle-down business hype approach. What do we developers get by learning the new dev platform? The opportunity to become more and more disconnected from the real workings of things, more dependent on the OS to do things like open files through a complex object model, more and richer object models for us to wade through to get other things we want done. I feel like MS is only concerned that IF I get an application working, I can NEVER port it out of their forest of products.

  • David Fung says:

    I agree with your original post that .NET does not offer anything crucial that is missing in VFP (at least in my line of work that is). So to me, I have little incentive to migrate from VFP to .NET.

    However, for those new to the field (aka haven’t had any experience in any development platform/tool), they probably will pick .NET (or Java) as their tool of choice. So say five years down the road, whether switching to .NET or not is a non-issue to these people because their life begin with .NET. And I suspect they will be the majority as time goes by.

  • Andy – I agree with you. I always look at it from a customer standpoint – ie – Can My Customers Afford this type of solution? So far, in the 30 or so months my firm has been evaluating this toolset and marketplace – the answer is still a resounding *NO*. Small Business Owners, my meat and potatoes, will NOT pay for the infrastructure THEY NEED just to run a Dot Net App.

    I’m also a big fan of metrics – and I look at that silly LOC metric to DO THINGS with data, specifically ONE RECORD, and I can still compare the 40 or so lines o code in MOST dot net languages to the 2 lines o code in VFP. Less Lines of Code, in MY shop, always means Less Time to Market – which for small business folk (again, my firm’s Meat and Potatoes) is a wonderful thing.

    I’m sticking with the Fox – its been a nice ride so far.

    mondo regards [Bill]

  • Anonymous says:

    Me, i’ve always use VFP. And i suspect i will always use it.

    And whenever i (frightened by those who say MS will eventualy let fall Fox) try .NET, i quickly go back to VFP, now frightened with all the sings missing in .NET that i have easily in VFP.

    Is like i had a BMW that can run all roads, and someone try to sell me a FIAT that runs better on Highways, with the promise that eventualy Highways will in the future lead to anywhere. For now i’ll keep the BMW.

  • I would like to add a brief case study:

    A year ago a software company in a poor Asian country decided that they "had to move from VFP to .NET" because of the potential clients’ perception that VFP was "old technology" and "not crash proof". Their competition also touted the fact that the competing applications were built on the latest MS .NET technology, and this was starting to cost the company in question some sales.

    So, the company flew in a consultant from the US to give them a jumpstart to the brave new .NET world. After four days of training, puzzlement, huge disappointment at the extra work required and sorely missing third party tools, jumping through hoops and loops to do "simple VFP tasks", as well as conceptual blocks all around, the trainees were left to their own devices.

    Today, the company in question is STILL developing all of their apps with VFP. .NET has not done them any good, yet they spent untold thousands of dollars for the technology, third party tools, infrastructure and training to support .NET. (And a thousand dollars is a LOT more money in a poor Asian country where subsistence wage is around $5/day than it is in the US)

    Why did they even try this, then? Because they wanted so very hard to at least APPEAR competitive on the Business Level, regardless of what the implications were on the Technology Level. Which understandably was a hard decision to make when the competition was breathing .NET down their neck.

    I’m using VFP here only as an example I happen to know. I’m sure the Business Battlefield is littered with many other utterly failed conversion efforts from VB6, Filemaker, Access, Cobol, Fortran,…

    Going from a mature technology (e.g., VFP) to an immature one (e.g., .NET) is kind of like moving from a sunny state (e.g., California) to a cold one (e.g., North Dakota). All of a sudden you realize that in order to go out you have to put on a hat and a heavy coat and mittens to deal with the elements, and you also have to preheat your car to get it started. It takes a lot more layers (clothes) to do the same thing (go out). And that, my friends, is one painful adjustment.

  • Well put, and thanks to the readers’ comments, because now I am sure that we are on the right track with VFP since 1996 and we intend to stay there!

  • Andy Kramek says:

    Those of you who know me well will already know that I have been saying since the first views of .NET went public that my opinion is that .NET will be the straw that breaks the camel’s back. In other words, I think that Microsoft has got the whole .NET thing so badly wrong that, in the long run, it could actually bring the company down. Interestingly Craig Bailey has posted something only the other day that takes a different slant on the question but which, I think, makes some extremely telling points. Check out his article right here:

    http://craigbailey.blogspot.com/2005/07/net-return-on-complexity-roc.html

    But back to my thoughts. Why do I think that Microsoft, a notoriously good marketing company, has got this one wrong? Well here, in a single sentence, is my reason.

    There is simply no defensible case for switching from an existing development platform to .NET!

    Now let me expand on this a little. First I must stress that I am totally impressed by and thoroughly in favor of ASP .NET! This is the tool for which web developers have been longing since commercial internet applications first began to be constructed. It is long overdue, and only looks like it is going to get better with time. So I am totally behind the ASP .NET initiative. But, alas, as for the rest of .NET, it is ill-conceived, poorly implemented and adds little or no real value to the existing development tools and environments. Consider this from the view of an existing application developer – why should such a person change their development environment and tools? Seems to me that there are three “imperatives” which drive such a change:

    · Technical Imperative (the most important!)

    · Infrastructure Imperative (often a major limitation)

    · Business Imperative (the least important!)

    Let’s examine each in turn.

    Technical Imperative

    Basically this states that the new environment will permit you to tackle tasks that, in your current development environment you simply cannot do. This is why I am so enthused about ASP .NET – it definitely has the technical imperative going for it.

    However, for the rest of .NET the case is totally different! What can you do in .NET that you cannot already do in your current development environment?

    Note that I am not saying that .NET cannot do some things better – of course it can (but by the same token it also does some things worse!!!). The key question here is what it can do that you cannot do with your current development tools? If there is something (and I don’t know what your chosen development environment is) then the second question is “Does it matter?”.

    My take on this is that organizations and people choose tools that are appropriate to their needs. (If it helps to use an analogy consider this: Does an electrician really need a automobile hub-puller? Probably not, but an auto-mechanic…?). By definition, therefore, anyone already developing software has the appropriate tools at hand and really does not need anything else! So unless there is an overriding technical issue that has hampered them in the past and which .NET allows them to solve, they have no reason to switch.

    My problem with .NET (in this context) is that I do not see anything that could possibly be construed as “new capabilities”. All I see is different ways of doing things that we can do already. Therefore it fails on the most important of the three imperatives.

    Infrastructure Imperative

    This states that an organization has been limited in its choice of development environment by the need to operate and support an existing hardware infrastructure. The imperative comes into play when, for some other reason than software development, that infrastructure is changed or upgraded so that environments that could not hitherto be supported can now be used. In other words, the driver here is the fact that something external to the software process has driven the change.

    The problem that confronts .NET is that its adoption typically REQUIRES an infrastructure change (i.e. hardware upgrade). So instead of being a concomitant option that becomes available when the change occurs for other (usually economic) reasons it’s adoption necessitates the change and therefore has direct long term cost implications.

    When taken in conjunction with the technical imperative above the combination is potentially ruinous.

    Business Imperative

    Now this is the drive on which Microsoft has, to date, based the entire .NET strategy (and in fact the entire corporate farm). This imperative, simply put, relies on fear and (technical) ignorance. The basis for adopting .NET has nothing whatever to do with it’s technical merits or requirements but it is done simply because of the perception that “competitors” are doing so!

    It is significant that most of Microsoft’s efforts at marketing .NET are not directed at technical personnel but at “Management” – particularly “Senior Management”. This reflects, I believe, the fact that they realized early on that they could not actually meet either of the imperatives for Technology or Infrastructure and that the only way to promote widespread adoption of their flagship new product was to rely on this approach.

    To date the take up has (reportedly) been “disappointing” and “slower than we had hoped”. The main adopters seem, on the whole, to have been large organizations where the non-technical approach works best. In smaller organizations, where decision makers are closer to the actual technology, I suspect that the take-up has been far less than most of us even realize.

    How can .NET hurt Microsoft?

    The key question is why did Microsoft bother with .NET? I believe that the answer lies in the business model for the corporation as a whole. For many years Microsoft relied on the ‘Upgrade’ model for their revenue. A new operating system was produced every two to three years and people rushed out in droves to buy it (remember the launch of Windows 95?). Microsoft Office was (and still is) the best selling office package. Upgrades came out and people upgraded. It has been estimated that Office Upgrades alone accounted for well over half (and I have seen estimates as high as 80%) of Microsoft’s revenue in the late 1990’s.

    The problem with this model is, of course, that it relies on people (and organizations) continuing to upgrade their software. As products reach maturity there is a limit to the number of ‘necessary’ new features that people will be willing to pay for – either in the Operating System, or in the Applications that they use. This was, I am sure, well understood by Microsoft who had to be aware that there was going to come a time when people simply would not bother to upgrade any more. Latterly of course, the rise of the Open Source initiatives has threatened both the Office application and even Microsoft’s flagship database SQL Server (which has not even been updated for 5 years now!) – why else the scramble to release first “MSDE” and now “SQL Server 2005 Express”?

    (Just for the record, I am writing this in Word 2000 running on a Windows 2000 operating system! Even though I have Windows XP, Windows 2003, Office XP and Office 2003, there is nothing new in any of them that I actually need. Not only did I have some compatibility issues (especially PowerPoint) when I tried newer versions, but I am already both familiar and comfortable with the “2000” versions – so why bother to upgrade?)

    So where could Microsoft turn for a significant new source of revenue? The answer they chose to adopt was, of course, to develop a comprehensive software development environment that would require investment to adopt and which, once adopted, would not be easy to get out of. We are looking at the result in .NET!

    Of course .NET is still in its infancy – the next release (Whidbey) promises more and newer things but, significantly, makes no commitment to maintain backward compatibility with the current version of things. Why? The official answer is so as not to constrain the development of the framework and the tools. The reality is, I suspect, that as with most new things the first versions were simply wrong. Now they have to be fixed and correcting those fundamental flaws whilst maintaining backward compatibility has proven to be impossible (else, presumably, they would be trumpeting the fact!)

    In the real world I believe that most software development is still done by small organizations (often only one or two developers) and unless Microsoft can convince this sector of development world in general to adopt .NET I do not see where the revenue to replace the ever decreasing stream of upgrade funds will come from.

    This is why I think that, in the medium to long term, Microsoft could be seriously hurt by their commitment to .NET to the exclusion of almost every other product in their range! I hope the crash won’t be too disastrous because Microsoft have been, on the whole, good for the industry. However, I still believe that the developer world is actually smarter than people at Microsoft give them credit for and that Microsoft are heading for a crash that will arrive sooner rather than later.

  • Anonymous says:

    What about 64-bit technologie? Next generation of computers will be 64-bit. Programmers will need tools to work/developer under 64-bit and the only tool from Microsoft is .NET

    I love VFP and agree 100% with Andy, but what can we do with this problem? Microsoft is not going to upgrade VFP to 64-bit.

    Sorry my poor english. 🙂

  • Andy Kramek says:

    RE: Sebastian’s comment:

    Well, Ken Levy has stated already that "Visual FoxPro will remain stand-alone Win32 based, and will run on 64-bit Windows in 32-bit compatibility mode. "

    This does, at least, mean that we can continue with VFP into the next generation of 64-bit computers. Of course, once 64-bit is the normal every day thing, then things may well be different. But that is a LONG way in the future. Right now I see now reason to change my development environment from VFP to .NET and, right now, I cannot forsee any change in that position in the next 3-5 years. After that, who knows?

  • Andy,

    you couldn’t be more wrong on this one.

    .NET is a *HUGE* step forward for a great many programmers, in terms of easy of use, productivity, and the ability to quickly and efficiently deliver solutions.

    C# is a HUGE improvement over C and C++ and brings a wealth of new possibilities to mainstream development.

    The .NET base class library is MUCH BETTER designed, structured, and implemented, than anything before that (from MS). That alone is a huge leap in productivity worth investing in. Just look at the seamless XML integration, the Web Services integration, and MUCH MORE.

    I’m sorry to hear that so many developers still "don’t get it" and try to talk .NET into oblivion – it won’t happen, guys – either get on board and benefit from the .NET momentum, or you’ll be left in the dust in a few years (once Longhorn and other services will be available to .NET API’s only)……

  • Andy Kramek says:

    Re: Marc Scheuner

    I am sorry but it really looks as if you didn’t actually really read the article but just gave the usual knee-jerk reaction. I have already said that I support ASP .NET and acknowledged that .NET is in its infancy – however, my thesis is that that for existing development shops with existing tool sets, there is no compelling argument to change.

    The claims (repeated by you) about "productivity" and "quickly and easily deliver solutions" are just not borne out by any evidence that I can find. In fact, the exact oppposite is true (see Craig Bailey’s article) or the comments by Don Sullivan (A senior IT professional at the Cleveland Clinic).

    All you offer is another unsupported, un-argued denial and a THREAT! You say I will be "left in the dust" in a few years.

    What I don’t see is the evidence that the whole business world is waiting for Longhorn? I don’t know of any organization that is saying "WE MUST HAVE LONGHORN"?

    I am sorry, I welcome your opinion and you have clearly bought into the Microsoft vision, but, unless you can offer some actual support for your views I have to reject them as merely more of the same thing that I am complaining about = "marketing speak".

  • re: Marc Scheuner

    The question was not "Is C# a huge improvement over C or C++?". The question was "What is the technical imperative to scrap your current development environment in favor of .NET?".

    As I see it, there really is no technical imperative except for web applications. There is a strong "MS manufactured business imperative", however, with the same kinds of "left in the dusk" comments/warnings/threats that you posted here (the stick), and promises of fast development cycles, stability, security, etc. (the carrot).

    My experience has been that businesses with existing, tried and true development systems move to .NET generally only because they have to have the .NET Stamp of Approval and Bragging Rights.

    I personally like C# a lot, and I use it every time I need to write web services or web applications. For desktop applications I always use VFP and save myself time and trouble, and my clients money and deadline embarrasments. It is not perfect, but it is clearly ahead of .NET as a development environment for database desktop apps.

    Having said that, however, I do believe that by .NET Version 3 it will finally be a stable, productive and well rounded and well supported development environment. Third versions for MS have generally been that way. MS is a tenacious corporation, and if it is critical for their long term plans, they eventually reach their lofty goals, even if the do have to trudge through vast marshlands (and drag their customers with them).

    I assume (and expect) that by .NET Version 3 I, too, will finally let go of VFP as my main development tool and use .NET for the majority of my work, on or off the web.

    This was the way with Windows, too. It took three versions of Windows to finally convince me to move from DOS to Windows (Version 3.11), because by then I didn’t need to suffer too many idiosyncracies, the platform was relatively stable, compability to future Windows versions seemed pretty likely, and there were plenty of good third party tools and utilities available to make the most out of that experience.

    Pertti

  • Hey Andy:

    I loved reading your blog. I am a VFP Certified MCSD (Visual Studio 6) developer and an MCAD Certified developer for .NET. I’ve used VFP since 2.0 (DOS) and have created many stand alone applications as well as a COM based framework that integrated VFP with the old ASP. I’ve also now had the opportunity to develop a website using ASP.NET and the .NET framework in general. I am also a strong proponent of software development frameworks. I’ve always used them, from Flash’s Codebook to F1’s VFP framework, Visual Promatix, etc.

    I agree with your statement about ASP.NET. For web development, it is an incredible platform.

    I also agree, in one sense, that .NET in its raw form is not that great of a platform for development. It’s large and complex and some parts are poorly designed (some class libraries). It is very difficult and takes quite a bit of time and money to become proficient enough in it to develop professional level applications … this is a problem.

    I also must interject that when using .NET with quality third party frameworks, most, if not all, of the inefficiency in the development process went away. By following the tenants of the framework I almost immediately fell into a best practice way of performing tasks (it should be pretty obvious that .NET is so large that developers can easily fall into the trap of doing many, many things the *wrong* way.) This resulted in being able to develop a website for a buddy of mine in about a month … http://www.fraudeducation.com. This website allows investigators to take courses and tests, it tracks each page of the course the user viewed, it also tracks each test question taken, the answer provided and the grade of the test (many, many more things but you get the general idea).

    In conclusion, when I attempted to develop an application with .NET in its raw form, I was overwhelmed with its complexity. When I began using Mere Mortals .NET software development framework, I was able to begin focusing on business logic and forgetting about .NET and it’s complexity. It was a welcomed relief.

    Thanks for listening,

    CTBlankenship

  • Jason Starin says:

    I’m honestly confused by this tact and this view.

    ASP.NET was first and foremost a solution to the woes of ASP. Active server pages have been caught in an endless struggle with script versus functionality. ASP couldn’t continue to compete with more flexible development languages like Java and the various products surrounding it.

    Then along comes C#, which completes some of the promises unanswered by even Java development. That alone was a major step forward, giving a non-VB language from microsoft that showed Microsoft could again lead in the development of a good operating language. Allowing a clear structure for the language to be emulated by Mono.NET is also very pleasing, since this allows competition with technologies like PHP.

    As an afterthought, to be sure, microsoft tacks on the windows form development which embraces several of the web based technologies incorporated into web form applications. This shouldn’t have been any suprise. The moment the browser started getting embedded into Windows, there was obviously a trend towards an IDE and the back end technologies to allow development of windows apps that could operate similarly to their web app counter parts. Eventually this could translate into the ability to advance both platforms with the same development environment and technologies. Microsoft’s coup is that their windows apps and their web apps can be made side by side, in the same language, sharing parts in each of their three tiers of development. As a matter of fact, some of the GUI encapsulations for Windows forms can be identical or use the same xml file for their designs!

    This has obvious advantages over old technologies. Even if Old and Tried workhorses like FoxPro can be used to build a windows app faster than any other language, how can it compete with the fact that to build a web app and a windows app, you have to have two different paths of development?

    If you follow the ASP.NET road map you build your web services so that they are DLL’s which can be consumed either as web services or compiled into your windows form executables. You make one change, the change ripples through. How can that be done with any other technology you’ve seen? To get the same effect you’d probably have to shuffle together several different technologies, use a bit of script, a language or two and then what are the support costs of that system?

    I don’t doubt that some application environments have their places, and ASP.NET is by no means perfect, but they’re growing by leaps and bounds.

    Before a claim that says the ship is sinking comes through, let’s remember that ASP.NET is just into 2.0 Beta, when FoxPro was at that level, everything was still in DOS.

    I’m pleasantly reminded of several discussions from old bulletin boards where the Pascal versus C++ debate raged, or the Pascal versus Fortran, or a wide host of COBOL programming debates.

    I’m hopeful for ASP.NET, and I see a lot of promise.

  • Anonymous says:

    OK, Andy, I have to fully disagree with you. I have a solid past in C++/MFC, PHP, and ASP. I have been programming in VB.NET for the last year. I have never been able to pick up a language and become productive with it as quickly has I have with VB.NET, and I have never found a language that is as enjoyable to program in as VB.NET.

    The largest problem that I see with your argument is that it is based simply from the viewpoint of a programmer, not from the viewpoint of a business owner or marketing person. While I do agree with you somewhat in that if you are familiar with a programming language, and .NET does not offer you anything new, then why should you switch? However, you are making the assumption that .NET does not offer anything new, and quite frankly, there you are completely wrong. Now, while technically, there are workarounds in other languages for things that are easily done in .NET, you cannot be as productive in another language as you can be in .NET. For example, I could take an MFC application that took me roughly a month to write that has about 25,000 lines of code in it and re-write it using VB.NET. The resultant application would only contain 10,000 lines of code and would have only taken me about 2 weeks to write. So, while the applications are functionally the same, from a business development standpoint, which is better? The VB.NET code is easier to go back and read, has fewer lines of code in which to hide bugs, and took less than half the time to produce (duh?).

    The largest problem with people who say .NET it not worth the migration troubles is that they have not explored both worlds completely. You have a solid background in a different language and you try to learn .NET, but you have a chip on your shoulder from the beginning because you don’t want to move. Therefore, you never try to embrace .NET, so you can never learn it. I have not met a single person that has ever told me that they like another language over .NET when they are fully familiar with both.

    And there are things that I can do in .NET that I couldn’t do in C++/MFC.

Leave a Reply

Your email address will not be published. Required fields are marked *