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.


Wednesday, August 25, 2004 6:40:49 PM (GMT Daylight Time, UTC+01:00)
This is much welcome news! As a developer of large applications (2 million+ LOC) with an relatively large installed based (12,000+ customers, 50,000+ desktops) backwards compatibility is very important to us, and anything that minimizes our pain on moving to new technologies is greatly appreciated. I think that the "incrementally improve while maintaining compatibility" and the "new version is automatically better without any extra work from you" strategy has in the past been one of Microsoft's greatest strengths so it's nice to hear that you're back in that camp.

Maybe the team responsible for the VB6-->VB.Net migration can get some of this religion :)
Paul Gibson
Wednesday, August 25, 2004 7:13:49 PM (GMT Daylight Time, UTC+01:00)
i can't tell you how much honest and humble reflection like this is appreciated. thanks!
Wednesday, August 25, 2004 8:30:02 PM (GMT Daylight Time, UTC+01:00)
I'm glad you said something now. I am just about to start writing the XML chapters in Pro C# 4th edition. I was working on the outline last night. So I wil take this to mean that you will not be steering everyone away from XmlDocument?
Thursday, August 26, 2004 1:50:53 AM (GMT Daylight Time, UTC+01:00)
I'm also very glad that XmlDocument is not going to be 'de-emphasized'. The DOM has always been more convenient for me.
G Mladenov
Thursday, August 26, 2004 12:09:13 PM (GMT Daylight Time, UTC+01:00)
While it sounds positive, I still believe DOM should be "de-emphasized" or at least to be "one of available XML stores", not "the XML store". But before we need better mature alternative.
Thursday, August 26, 2004 2:11:25 PM (GMT Daylight Time, UTC+01:00)
Maintaining continuity and compatibility is a true indicator of being passionate about winning customer satisfaction and retaining the customer base.

On the other side, strategic considerations may require preparing the introduction of new platforms and technologies.

Therefore, the problem is how to avoid both extremities and assure continuity and compatibility while introducing new technologies and platforms in the most non-disruptive way possible.
Dimitre Novatchev
Tuesday, August 31, 2004 12:55:05 AM (GMT Daylight Time, UTC+01:00)
I;m not sure if I understand well - does "Similarly we will keep the new and improved &lteraser&gtXPathEditableNavigator&lt/eraser&gt XPathNavigator class" mean that:
- there will be no editing support for non-dom xml sources ? (most important for me)
- XPathNavigator will be used with new XmlDocument class ? (propably no ;p)

and another important question
- will be there any schema support for non-dom xml sources (again most important for me)

please please let me know - I;m makeing architectural decisions now ;p

ps. it will be best to keep new xpathdocument2 while improveing xmldocumnet
radek tereszczuk
Tuesday, August 31, 2004 1:24:06 AM (GMT Daylight Time, UTC+01:00)

> there will be no editing support for non-dom xml sources ? (most important for me)

There will be through the XPathNavigator API if the non-DOM implements IXPathNavigable.

> - XPathNavigator will be used with new XmlDocument class ? (propably no ;p)

It will. In v1.1 you can already navigate an XmlDocument with its XPathNavigator. In v2.0 you will be able to edit the XmlDocument through its XPathNavigator

> - will be there any schema support for non-dom xml sources (again most important for me)

Yes, if they implement IXPathNavigable since the XPathNavigator will have a SchemaInfo property which exposes the PSVI.
Monday, September 6, 2004 8:06:52 PM (GMT Daylight Time, UTC+01:00)
Now if the new way of dealing with Xml documents (or even the existing way) would transcend to the rest of the .NET Framework, and Web services with ASMX and WSE in particular. Unfortuately, that's not going to happen. Read more: http://weblogs.asp.net/cschittko/archive/2004/09/06/226114.aspx
Comments are closed.