Bleeding edge and far from it

I am just back from WinHEC and while there I realized that many people including a number from Microsoft don’t distinguish developing for the leading edge from living there. I am known as a guy who has done a number of things that Redmond had said “Windows is not capable of doing” and technologies that Microsoft was later proud to show off once they were working. 

When it comes to my tools, I am far from the bleeding edge.  For instance, though I recently started using the latest Visual Studio, most of my work is still done with VS6.   I like the new Studio, but I trust VS6 and that version produces code that for the most part needs no libraries other than the standard system lib’s to support it.  I use Office XP and probably will not move for a long time, since I once had a terrible experience of not being able to send a customer a promised document, since the conversion back to the format the client was using did not work well.


I am not alone in this attitude; many of the developers I respect the most stay far away from the leading edge for their work environments.  In this way we are like Seymour Cray, who required that the parts for his designs were in production and testable even though the systems he was designing were years off.


The challenge here is that Microsoft does not seem to understand this.   The WDK team was proudly pointing out the features and fast updates with online MSDN, when most developers use the local documents.  One of the new features with the MSDN stuff is a wiki capability that is supposed to be monitored by using an RSS feed.   Most of the senior developers I know do not monitor this, since Microsoft’s previous generation of tools do not support RSS!  Another RSS problem is that when Microsoft “improved” its blogging site, it dropped email notification of blog postings, because RSS was available in all the brand new tools.


Another example from WinHEC was the Windows Driver Testing Framework.  This tool assumes you are using the latest Visual Studio to develop with managed languages using the full strength of COM.  I know of almost no respected driver writers who know how to do this, and even fewer who would want to. 


It has to be confusing for the WDK team because their core product is the exception that proves the rule.  Over the years, the development community has found that BETA and just released versions of the DDK are excellent so we trust using these in our day to day work.  Unfortunately, few other teams in Redmond inspire this confidence.


So, Microsoft, if you want us to keep developing on the bleeding edge, give us tools that do not force us to live there.


2 thoughts on “Bleeding edge and far from it

  1. Sorry I missed WinHEC and a chance to see you. 🙁

    I agree with you that some recent MS tools for driver developers seem from another world altogether.

    Apparently the Windows Driver Testing Framework falls into the category. I believe that the Windows Driver Testing Framework is the foundation of the DTM, and I can certainly say from several months of misery and frustration with DTM that it is not a solid foundation.

    If a test failed with the legacy HCT a developer knew the it was likely that his or her driver was faulty. If a test fails with the DTM it is _possible_ that the driver is faulty, but also likely that the DTM framework or the DTM test being performed has a bug.

    The “KISS” principle (“Keep it simple, stupid!”) is a key cornerstone of driver development and testing. Some folks at Redmond are loosing sight of this.

  2. I think DTM is based on the internal Microsoft WTT (windows test tools?), minus some stuff like integration with their bug database and such.

    If memory serves from the MVP summit, there is a group on the testing side that put the testing framework together, along with the device simulation framework. Both look interesting, but I certainly don’t have time to mess with COM.

Leave a Reply

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