.NET Reality check, my €0.02

S.B Chatterjee refers to an article which is a follow up on a blog by Michael Earls concerning a .NET reality check. (If this sentence sounds a little complex, it is, but just start with Michael's excellent blog entry and you're on track :))

I fully agree with Michael Earl. For the past 4 months or so Microsoft and its employees in general published a lot of material about upcoming technologies like Longhorn, Whidbey, Yukon, XAML and other goodies that will make our life easier than it is today. However these technologies are at least 1 year away, if not more, and after that the 'adoption' phase begins which takes at least another year before a majority of people is using them. All that hype is not usable today, as we, developers, are still using .NET 1.1, VS.NET 2003 or even earlier versions. This is frustrating.

For years Microsoft has done this, it's nothing new: release a technology XYZ, keep releasing marginal examples on a marginal schedule and start hyping XYZ's successor shortly after the release of XYZ. For years I too have accepted this approach and thought it was 'normal'. But the last couple of months, especially with the start of a lot of MS blogs, I realized that it isn't normal, it's bad. "It's always better in the Next ReleaseTM", is a well known slogan in software land. MS' behaviour with the hype about next-gen technology is the ultimate implementation of that slogan. And it's frustrating for today's developers, working with technology that's available today (.NET 1.1, VS.NET 2003).

It's frustrating because there are no fixes available nor announced for problems with today's technology, like the dreaded ASP.NET designer flaws in VS.NET, flaky winforms controls, bad design in essential technology like the XmlSerializer (no cyclic reference support, interpretation of IXmlSerializable is flawed and the interface is not documented etc.). What's presented as the 'next big thing', Whidbey/.NET 2.0, is said to solve all of these problems and more. However, it's at least a year away till the early adopters are starting with VS.NET 2004 (2005?) and the majority will follow later, at least 6 months after the initial release date. Besides that, Whidbey will allow you to compile code targeting .NET 2.0 only, you can't compile using the .NET 1.1 compiler, which means your customers will have to upgrade to .NET 2.0 as well.

Every day I check the MSDN 'recently posted' page and I estimate that at least 50% of the articles posted are about technology 1 year or more away (today, at least 11 of the 20 articles listed). Not a single one is about how to deal with problems we all face or will face or have faced with todays technology. Searching the Knowledge Base is as frustrating as reading about the 'solution to all your problems'-articles about tomorrow's technology not available to us: you have more luck searching google groups and in a lot of occasions find fellow developers with the same problems and the same lack of solutions.

Microsoft, stop it. Stop the hype for material we won't see on our desktops for at least a year. Instead give us solutions for the problems a lot of us face today with today's technology: fix the flaws in VS.NET 2003, solve the problems with XmlSerializer so more people can write webservice compatible code using the now undocumented IXmlSerializable interface (which is documented in Whidbey, so a solution is already found apparently). It gives me the idea that you want to obfuscate the problems of today's technology with pretty pictures about tomorrow's technology which seems to solve all our problems for good. I don't think that's a good thing.

I understand that developers working on tomorrow's technology want to tell the world how cool it is (or will be) and that others, naive as I was for years, want to talk about these new technologies for days, weeks, even months. I hope you, Microsoft, will understand that all that hype is not helping us today and it draws attention away from the serious lack of customer support for today's technology. If I would treat my customers like you do, Microsoft, I wouldn't have a single one left, and I wouldn't blame them.

10 Comments

  • Valid point, although I think a lot of effort does goes into current-version-software support - but not necessarily on the weblogs.

  • If that's true, why isn't it showing? Can you point me to a set of fixes to problems in .NET 1.1 or better: vs.net 2003? I can't.

  • Hmm...well, Weblogs are not really 'customer support forums' - in the actual newsgroups and ASP.NET forums, MS employees pretty much exclusively talk about .NET 1.1 - I do agree that there's too much emphasis on MSDN to do with Longhorn and Whidbey (for Longhorn at least, this is probably the whole marketing ploy thing - trying to increase the number of Longhorn apps way in advance of launch to increase the 'critical mass' for product launch).

    For Weblogs however, MS employees are in no way obligated to provide support in any capacity, they are however talking about the cool new technologies they work with (as we all are) - they just happen to be working with technologies that most of us won't be using commercially for 2-3 years yet...

  • Good point from Frans though...I've seen lists of bugs, but very few 'here's the bug' and 'here's how to fix it' type posts (usually have to trawl through dozens of Knowledgebase articles which are only vaguely related then discover I have to call PSS to get the fix - which I can't redistribute to my clients...). On the bright side, .NET Passport is WAY worse...it doesn't even work properly on .NET Server 2003!

  • Scott: I don;t consider weblogs as 'support', though they add to the hype building, but I don't consider them the cause of the frustration, the general channels towards developers are the cause of it (PDC, DevDays, MSDN etc.) and the lack of support which IS there. I read the C# newsgroup mostly (and the ADO.NET newsgroup) and I never see an MS employee explaining things in the ADO.NET newsgroup and rarely in the C# newsgroup. It's on the shoulders of the MVP's and other volunteers however these people can't fix broken code in .NET. Reading the VS.NET newsgroups is even more frustrating. I mean, if you count the amount of threads about the project listing on the start page in vs.net, you'll be stunned.

  • Too often the examples provided by MS are trivial.



    Design time support in VS.Net is a great example of this.



    I can't sell designers (people) on the idea of something that says "[This is the control]", they wont accept it.



    I read Nikhil's book recently and it was a great review, but there could be a book that size just on design time.

    Lots of people here have read the book, and they make controls that display "[the control is here prop1 = someVal]"



    I have gone down the rabbit hole with designers.



    It is commonly believed that you cannot get at the web config at design time and yet to do so is trivial once you realize how.







  • (This is my opinion and my opinion only, and has nothing to do with my employer’s opinion. This post is presented as is and all the usual legal warning…)



    I don't really agree. "Hype" tends to imply some sort of marketing buzz, which purpose is just to get people excited about partial information. I do think there is a deliberate marketing effort put into "hyping" Whidbey from Microsoft, I also believe most of it (in this community at least) comes from MS employee on their blog that just talk about their job and what they're doing. They don't hype "the future", they talk about their present and what they are doing every day of the week. I completely understand that what they're talking about is often months away or more and this is the source of a lot of frustration. But this is a radical change from the past where MS would just keep everything more or less secret until quite late in the development cycle.



    I also get the frustration of making every answer to most problems “the next version is going to solve that”. For the most part, working on the web minimize that problem: upgrading and evolving software can be a continuous process. You develop an improvement to the current version; you can just deploy it to the server. The dependencies are minimal.



    So why does it end up being like that? For the most part, I think this is due to the nature of shipping “shrink wrapped” software. When we code a given version, at some point we say “stop” and we don’t add any new feature, we stabilize the code for a while, then we branch the tree and ship a beta. At this point we have two branches, the current branch to which we start to add new things again and the “beta branch” we’re trying to get stable enough to publish. The fact that we have to stop adding things to get the software above what we think is the quality bar for a release creates the “it’s all going to be better in the next version” problem. We don’t touch the beta version, except for bug fixing and as we’re getting closer and closer to the ship date the bar on what’s an acceptable change keeps rising until we only accept critical fixes (security is a good example).



    Meanwhile the other version is already far along and moving thing from one branch to the other is very time consuming since a lot of things have moved and changed. So once the software is shipped, and to be honest, even once it’s in the beta stage; it is very costly to do something about an issue in any other place than “the next version”. That’s the precise reason why we want people to take the opportunity to review what we’re doing before reaching that point.



    I am not sure I made my point clear enough for everyone to understand :) And I am not sure my English is very good today either... but in the end I think it's all a matter of balance in the way we present things. We tend to get excited about the work we do (I mean, show me a programmer who isn't?) and thanks to blogs some of us are now talking directly to the public. But I believe that's the cost of getting the raw information and being able to participate in the feedback loop early on. Is that "hype"? I personally don't think so. Do I like it when people get excited about what we're doing in Whidbey? I sure do and it's a great motivation.



  • Oh, btw, reading answers that came while I was typing this message I completly agree that when you search for something on MSDN, beta software should be in an independant section and you should be able to limit your search to "current technologies only" easily.



    Once again I think this comes from a different reality for MS employees and other developpers. For MS the present IS the next version and when you're burried every day in whidbey stuff, you're excited about it, it really takes an effort to step back and realize that most of people are using Everett. I personally think this is something we need to work on harder in the future and your post is a great way of making us realize that.

  • I'm also getting a tired of the whole FVPS (Future Version Promotion Syndrome) going on. It's not just MSDN, it is also GotDotNet, ASP.NET and countless other websites trying to show how cool and on-the-ball they are by publishing articles on all the great things we'll be able to do....one fine day, subject to countless features changes and things that got dropped because there wasn't enough time to put them in etc.



    Enough already....keep us informed, yes....swamp us with endless articles on how cool the "new" stuff is compared to the current version us schmucks have to use is...no!

  • Couldn't agree more.

    We've been struggling with various bugs/shortcomings in VS2003 (incl: WindowsFormsParkingWindow; disappearing user controls; corrupt Win Forms; lack of stability of fundamental controls like the Toolbar).

    Unfortunately, at least some of these are *still* happening in Whidbey (with release probably Q1 2005).



    I can't, and haven't ever been able to wait until the *next big thing* in order to fix current problems.

    With the radical change in VS Longhorn pending, I really can't see MS doing much rework of existing Win32 issues in the Whidbey release.

    They are aware of the issues though.

Comments have been disabled for this content.