The MSDN Camp vs. The Raymond Chen Camp


A few months ago in Joel Spolsky’s  How Microsoft Lost the API War  he wrote

There are two opposing forces inside Microsoft, which I will refer to, somewhat tongue-in-cheek, as The Raymond Chen Camp and The MSDN Magazine Camp.

The Raymond Chen Camp believes in making things easy for developers by making it easy to write once and run anywhere (well, on any Windows box). The MSDN Magazine Camp believes in making things easy for developers by giving them really powerful chunks of code which they can leverage, if they are willing to pay the price of incredibly complicated deployment and installation headaches, not to mention the huge learning curve. The Raymond Chen camp is all about consolidation. Please, don’t make things any worse, let’s just keep making what we already have still work. The MSDN Magazine Camp needs to keep churning out new gigantic pieces of technology that nobody can keep up with.

When I first read the above paragraphs I disagreed with them because I was in denial. But as the months have passed and I’ve looked at various decisions my team has made in recent years I see the pattern. The patterns repeats itself in the actions of other product teams and divisions at Microsoft. I know realize this is an unfortunate and poisonous aspect of Microsoft’s culture which doesn’t work in the best interest of our customers. A few months ago I found some advice given to Ward Cunningham on joining Microsoft which read

 Take a running start and don’t look back

  1. Recognize that your wonderful inventiveness is the most valuable thing you will own in a culture that values its employees solely by their latest contributions. In a spartan culture like this, you will rise quickly.

  2. Keep spewing ideas, even when those ideas are repeatedly misunderstood, implemented poorly, and excised from products for reasons that have nothing to do with the quality of the idea. When you give up on communicating your new ideas, you will just go insane waiting to vest.

The Microsoft culture is about creating the newest, latest greatest thing that ‘changes the world’ not improving what is already out there and working for customers. When I read various Microsoft blogs and MSDN headlines about how even though we’ve made paradigm shifts in developer technologies in the recent years we aren’t satisfied and want to introduce radically new and different technologies all over again. This bothers me. I hate the fact that ‘you have to rewrite a lot of your code’ is a common answer to questions a customer might ask about how to leverage new or upcoming functionality in a developer technology.

Our team [and myself directly] has gone through a process of rethinking a number of decisions we made in this light. Up until very recently we were planning to ship the System.Xml.XPath.XPathDocument class as a replacement for the System.Xml.XmlDocument class. One of the driving reasons for doing this was XPath and XSLT performance. The mismatch between the DOM data model and that of XPath meant that XPath queries or XSLT transformations over the XmlDocument would never be as fast as XPathDocument. Another reason we were doing this was that since the XmlDocument is not an interface based design there isn’t a way for people who implement their own XML document-like classes to plug-in to our world. So we decided to de-emphasize (but not deprecate) the XmlDocument by not adding any new functionality or performance improvements to it and focused all our energy on XPathDocument.

The problem was that the XPathDocument had a radically different programming model than the XmlDocument meaning that anyone who’d written code using the XmlDocument against our v1.0/v1.1 bits would have to radically rewrite their code to get performance improvements and new features. Additionally any developers migrating to the .NET Framework from native code (MSXML) or from the Java world would already be familiar with the XML DOM API but not the cursor-based model used by the XPathDocument. This was really an untenable situation. For this reason we’ve reverted the XPathDocument to what it was in v1.1 while new functionality and perf improvements will be made to the XmlDocument. Similarly we will keep the new and improved XPathEditableNavigator XPathNavigator class which will be the API for programming against XML data sources where one wants to abstract away what the underlying store actually is. We’ve shown the power of this model with examples such as the ObjectXPathNavigator and the DataSetNavigator.

It’s good to be back in the Raymond Chen camp.


Comments (26)

  1. AEB says:

    Can you clarify what you mean by "we’ve reverted the XPathDocument to what it was in v1.1"?

  2. > Can you clarify what you mean by "we’ve reverted the XPathDocument to what it was in v1.1"?

    It means the XPathDocument will go back to looking like http://msdn.microsoft.com/library/en-us/cpref/html/frlrfSystemXmlXPathXPathDocumentClassTopic.asp instead of like

    http://lab.msdn.microsoft.com/library/en-us/cpref/html/T_System_Xml_XPath_XPathDocument.asp

  3. I’m currently looking at migrating a ~65,000 web app written in classic ASP to ASP.Net. However it seems that the upgrade path is to rewrite from scratch. This is unpopular with me and no doubt our customers. The problem is that session and application data is not shared between ASP.Net and classic ASP. This means that I cannot decide to write just one page in .Net, I have to rewrite the whole app in .Net.

    I am looking at some different means of sharing this information, but most of the solutions either mean a significant speed hit and/or have security implications. In the end I might well have to keep coding in an inferior language.

  4. Ben Bryant says:

    Its impressive that you display the humility to frame yourself (and Microsoft) within Joel’s paradigm. Microsoft is not a bad company of course, but its developers are not immune to this lazy inclination: throw out the old since the new stuff is going to be so cool even if it never gets much past half baked. You are in a position to guide Microsoft’s XML API policies and its important to strive for real value for the customer. There are a lot of issues to weigh, but one would hope there was an overall vision allowing you to keep the core objects reuseable. Best wishes.

  5. Please don’t change XPathDocument again from the .NET V2 stuff. I really like it, it works well for me in a way that the class DOM just doesn’t.

    I can’t quite put my finger on it but it fits the way my head works so much better.

    Now I’m wondering if I’ll have to rewrite my code 🙁

    Still thats my problem.

  6. Peter,

    What do you like about XPathDocument that won’t be present in XmlDocument. We still plan to ship the XPathNavigator as an editable XML cursor over representations of XML documents. If you’ve gotten used to using XPathEditableNavigator & XPathNavigator for working with XML in Whidbey beta 1 then that experience will be preserved.

  7. Jiho Han says:

    I don’t know much about XmlDocument vs. XPathDocument. This whole MSDN vs. Raymond Chen thing bothers me though. Why should these compete? Can’t we have both? I read the original post by Joel but I don’t think I totally agree, especially his point regarding web being the platform for applications(sorry for paraphrasing). Same with this debate on MSDN vs. RC. It’s good that there are groups in MSFT that seek to keep the APIs compatible but if that was the only effort by MSFT we’d never have things like XAML which I am really excited about. Personally I really like the MSDN camp even if they change their mind every so often. I think sometimes you just need to let go of the past and move on. We moved on from DOS to Windows. I feel as if the current .NET effort by MSFT is of such significance that will bring computing to yet another level that it is worth doing away with the old. Now I’m not sure whether that line is at .NET 2.0 or at WinFX. You folks will will figure it out.

    Like I said, I don’t know much about XmlDocument vs. XPathDocument. All I know is that I don’t want to be held back innovations for compatibility sake. Do I want my Xbox to be compatible with Atari? I’d take it if it came free but I really couldn’t care less.

    Just my 2 cents…

  8. Oh good. It’s just you’ve crossed out the XPathEditableNavigator in your piece. I think I like the fact that it’s cursor based. The current entry on my blog is a pretty good approximation of why I prefer the XPathDocument stuff to the DOM. The DOM feels very "academic", but the XPathDocument feels much more "real world".

    Little bits like XpathNavigator.ValueAsDecimal just feel right. I’ve recently spent quite a bit of time working with XML and I find myself using XPathDocument by default.

    It’s interesting this time around with the current Beta1 and upcoming CTP I’m actually writing "real" code with it rather than just looking at .NET as an interesting new technology. This is always a risky proposition as features may get chopped for shipping (but then I’ll take the chance) and some of the newer features like generics really help our code base out.

    This is also really fresh in my mind as I started some code recently using the DOM and changed to using XPathDocument as it was just plain easier. Sounds like the next issue of the CTP is out soon so I’ll just have to wait for now.

    Right now I suppose I fall in between the "Raymond Chen" camp (Keep it like .NET 1.1) and the "MSDN Magazine" (We’re all moving to Longhorn) camp. Personally I’m really getting to grips with VS.NET 2005 and having a really productive time, longhorn is too far away and commercially I can’t see it being viable as a desktop platform for six or seven years. I suspect MS will HAVE to introduce some Win32s like technologies to speed up adoption of Longhorn (Avalon lite?)

  9. James Risto says:

    Ok yes I see some evidence of the evil side of constant change. Perspective … however; think about how much legacy Windows supports and how much investment MS makes to keep stuff running. Trade off; Apple/Jobs revs stuff and way more stuff has to be redone … but they have less legacy testing. With MS, perhaps I continue to get value from old-old paid-for apps.

  10. Dare, how dare you? I did not think you had it in you just because you have it on you. It is pleasant to see the words of a Microsoft employee of your stature reaching out for what is correct, overriding the temptation to deceive shareholders with pleasant words of nothingness.

    Keep producing substance!

  11. It is nice that someone in MS recognizes the problem.

    I believe that the all new syndrome is behind the (paper) windows programming magazines deaths. Since they were all about the leading edge, they became irrelevant to what the readers were doing.

    Today we se a lot about .Net and friends and new scripting languages. But the people in the field are still using VBA and VBScript. So instead of improving on what is there, Microsoft is gambling with the loyalty of the developers: If I’m going to do something new, should I go with MS Office or become the big guy in OpenOffice? Answer: It is still better to go with MS Office because the OpenOffice people can’t be trusted to keep things backwards compatible (they have screwed up at least once). However things can change.

    greetings,

  12. Opensource and the internet are forcing professionalism into anything related to software. We are seeing a more professional Microsoft day by day.

  13. I only ever wanted one thing from Microsoft tools – stability. I happily trogged and suffered my way through paradigm shifts and bit counts. Now- what could be more stable than Visual Studio 6.0? It never changes – very seldom a patch comes along – but this is usually the OS part (security fixes to MDAC, etc.). That’s great. I’ve never had so darn much fun programming after 20 years. Leave it all alone. I’m happy. Well, make it free and there’d be alot more of us.

    XML is still relatively young for a technology. Maybe I’ll just wait a little while longer until it gets as stable as VS6.

  14. Aaron says:

    Wow, Dare, I’m super-impressd that you have the guts to admit this publically. Of course, XPathDocument is chump change compared to the vast changes that Joel was talking about. But just the fact that you see a problem is awesome. Just awesome.

  15. Michael says:

    I’do not think you’re really back in the Raymond Chen camp. You’re talking about not doing breaking changes to the big new WinFx (.NET 1.1) API.

    I appreciate this of course, but the older XML implementations MSXML4 and MSXML3 haven’t been updated for a year. And the very fact that MSXML3 is still around, because MSXML4 was a breaking change, that Microsoft itself was not willing to take shows the problem.

    But i don’t agree with Joel’s point, because evolution means, that older things die out sometime. It will just take its time. But when WinFX is mature no one will even WANT the old MSXML3 or 4 API back.

  16. Gary Kenward says:

    The market, as much as the integrity of people like Dare are pushing MS towards supporting developers better. Witness the recent announcement concerning MS opening up Windows CE. Customer support has never been MS’ strength, and Dare’s observation about focussing on innovation over refinement speaks volumes.

    Many enterprises have simply stopped upgrading to the latest and greatest IS product, regardless of the vendor. This trend has impacted the software industry the most, as upgrades (or even new versions) are a major portion of the revenue stream.

    Oh, and btw, it has nothing to do with open-source. As far as I am concerned, MS support for customers is at least as good as open-source support. The only difference being that with open-source you have the illusion of being able to dig into the code and fix it yourself.

  17. B. Jones says:

    I get very tired of Microsoft making us rewrite everything. Case in point, the news that DirectX will be discontinued for the latest and greatest thing in Longhorn. They did this before, after dropping DirectX Retained Mode without so much as a whimper. Anyone unlucky enough to have used it (like us) had to rewrite everything, and no shell layer would do, we had to redo *everything*. And now the whole DirectX? This time we’ll rewrite it… in OpenGL. Because we know if we rewrite it in any Microsoft API we’ll be rewriting it again in a few years.

    Microsoft need to realise the Win32 API *is* their leverage. And if they make life too hard for those developers who use it (instead of writing for the web) they’ll drive us all off.

  18. barry.b says:

    >> The patterns repeats itself in the actions of other product teams and divisions at Microsoft.

    so what is being done to address this? where is the overall quality control that provides the consistancy? what process is reconciling the "great race forward" Vs backwards compatability?

    totally re-writing ASP to ASP.NET is one case in point*. For me, I’ve not bothered to upgrade from win2k server and Office 2002 – there’s nothing new for me. And I’ve given up on ASP in favour of MACR’s ColdFusion MX – because it’s just as fast to develop in AND CAN RUN ON LINUX (and OSX).

    (*to illustrate the point, CF5 code can be run on CFMX systems without change, and can have CFMX extentions added to it without any pain whatsoever. try that in an aspx page!)