Remember this article? Remember when I suggested that BEA was in a unique position to lead Microsoft into the enterprise by supporting .Net in its servers? They're not all the way there yet, but here's the opening shot. Great move on BEA's part, and this can only help Microsoft.
I saw an article today that struck a nerve. I ran across it first on Slashdot, and then again on a Joel on Software forum post. The subject of the original article was the use of .Net in Vista. Richard Grimes has done what appears to be a pretty extensive analysis that shows MS isn't really using .Net for much. I posted a response on Slashdot and on JOS, and I've copied it here becuase it's my post. -g-My Response to Grimes' article:
There are some very legitimate reasons for us to look to Microsoft to use .Net extensively in their own products, including parts of the OS.
Readers here have seen the "dogfooding" idea, and have seen lots of arguments for why this makes sense in terms of getting requirements and design right. For a framework as sweeping and critical as .Net, that means real use in real apps by Microsoft. Now.
I don't think there are too many people who would expect low-level code to be written in .Net (kernel, drivers, etc.). But lots of stuff in a modern OS distribution is really bundled applications. As "JSD" pointed out, components like Outlook Express are bundled applications, not core OS components. Survey 1000 people and ask if they'd rather have sucure, bug-free browsing and email or have Outlook Express run 2% faster. Anyone have any doubt at all about the results?
Besides, the argument that unmanaged code is faster than managed code falls pretty flat on me. I completely agree that a good coder should be able to beat .Net with C++, but one of the reasons for a framework like .Net is that you want to make most apps perform very well, rather than just a few apps perform exceptionally well, and the rest run like crap or never get finished at all. A reasonably competent developer should be able to pick up a framework like .Net and use objects and data structures that are already developed, tested, and optimized. The reult may not be as fast as recoding the exact right algorithm in a native language, but for most developers and most development, they're going to end up with a better app than if they'd written it from scratch. That's why we use high-level languages, folks.
I think what this really points to is a combination of two factors, both of which are a little unsettling.
First, Microsoft is subject to the same product planning dynamics as the rest of us. For existing code and existing apps, virtually any incremental change will be more economical and less risky when built on an existing code base. Even the iffy cases will *appear* less risky when built on an existing code base. In order to undertake an architectural change, you have to have a pretty compelling reason to do so, and a good bit of courage to shelve the old stuff and move forward. This hasn't happened in a meaningful way in Vista.
Why is this disturbing? Simple. This points to the depth of reengineering that's going into making the OS and apps more stable and more secure. Very often, the right thing to do when fixing a bug is to find the specific pinprick in the code and patch it. Sometimes, however, when you start to accumulate enough bugs in one place, you have to consider whether there's a systemic problem in that area. In those cases, the only way to stop the bugs for good is to fix them systemically -- ie, to re-engineer that part of the app. If this is happening anywhere in the Vista code base, why wouldn't it be happening on .Net?
Which brings me to disturbing point #2. The release date for .Net 1.0 was what - 2002? And it's not like it snuck up on anyone. Let's give MS the benefit of the doubt and say that they all knew about it in 2000 / 2001, so it's been five years, easy. That's plenty of time to work out the bugs in a framework that they expect the rest of the world to build apps with. We've had the .1 releases, and we've had the hotfixes and service packs. It's got to be production-ready now, right? So why isn't it showing up in more of MS's own distributions?
It's either because any MS OS release is really a bunch of pretty small changes scattered across a staggering number of individual files and components such that MS can't justify rewriting any of the components, or because MS has, as Grimes concludes, lost confidence in .Net.
I'm a fan of .Net. I'd like to see it succeed. One of the critical factors for its success is for it to reach a critical mass. It's time for MS to step up and help .Net hit that critical mass.