Partager via

The MSDN Camp vs. The Raymond Chen Camp

  • Article

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

  • Anonymous
    August 25, 2004
    Can you clarify what you mean by "we've reverted the XPathDocument to what it was in v1.1"?

  • Anonymous
    August 25, 2004
    > 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

  • Anonymous
    August 25, 2004
    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.

  • Anonymous
    August 25, 2004
    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.

  • Anonymous
    August 26, 2004
    The comment has been removed

  • Anonymous
    August 26, 2004
    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.

  • Anonymous
    August 26, 2004
    The comment has been removed

  • Anonymous
    August 26, 2004
    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?)

  • Anonymous
    August 27, 2004
    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.

  • Anonymous
    August 27, 2004
    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!

  • Anonymous
    August 27, 2004
    The comment has been removed

  • Anonymous
    August 28, 2004
    Opensource and the internet are forcing professionalism into anything related to software. We are seeing a more professional Microsoft day by day.

  • Anonymous
    August 29, 2004
    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.

  • Anonymous
    August 29, 2004
    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.

  • Anonymous
    September 01, 2004
    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.

  • Anonymous
    September 09, 2004
    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.

  • Anonymous
    September 13, 2004
    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.

  • Anonymous
    September 14, 2004
    The comment has been removed

  • Anonymous
    July 10, 2007
    PingBack from http://davidsidlinger.com/blog/2007/07/10/feeding-the-revenue-beast/

  • Anonymous
    July 10, 2007
    PingBack from http://davidsidlinger.com/blog/2007/07/09/feeding-the-revenue-beast/

  • Anonymous
    June 09, 2009
    PingBack from http://quickdietsite.info/story.php?id=2163

  • Anonymous
    June 17, 2009
    PingBack from http://pooltoysite.info/story.php?id=1699