Insights into Microsoft
A couple of days ago, The Wall Street Journal ran an article,
titled “Battling Google, Microsoft Changes How It Builds Software” (also linked from Slashdot), which had a couple of points in it which I found interesting. In fact, while the article was intended to put a positive spin on issues, I found the amount of problems it uncovered with Microsoft’s software engineering processes to be totally astounding.
Let’s ignore all the the potential wisecracks and cheap shots about statements such as the one that Microsoft “cranks out a new, generally bug-free version of basic Windows every few years” (Yeah! when’s the last time MS shipped a bug-free version of Windows?). Go to the Slashdot article comments if this is what you’re looking for.
At the beginning of the article, we learn that “Longhorn was irredeemable because Microsoft engineers were building it just as they had always built software.” — which must have been pretty bad. This insight then leads to drastic changes. The article tells us that “Microsoft would have to throw out years of computer code in Longhorn and start out with a fresh base. […] Mr. Allchin had announced to hundreds of Windows engineers that they would “reset” Longhorn using a clean base of code […]“. Basically, as the Slashdot article sums it up, starting from scratch. From the depths of my (terrible) long-term memory arose a vague recollection of an article I had read some time ago, specifically in “Joel On Software”. In his article titled “Things You Should Never Do, Part I”, dated April 06, 2000, Joel Spolsky — himself a veteran Microsoft guy (now CEO of his own software company) — calls rewriting a software product from scratch “the single worst strategic mistake that any software company can make” (his emphasis). Joel’s posting states that by starting over, you end up shipping old code for an unnecessary long time, making the customer wait for the new product, while contemplating a move to a competing product. In the end you lose customers this way. And this may well happen with Microsoft putting off the Vista release for over a year, as opposed to the announced shipping date. At least in the corporate (server) software world, MS is losing ground.
Even worse — when starting from scratch you spend tons of money writing code that already exists. Well, Microsoft has very deep pockets. So spending inordinate amounts of money writing old code might not be as big a problem as it would be for ISV’s. The issue of losing market share is a very real threat, though.
What makes Microsoft think they can pull it off this time? The article makes it sound like Microsoft is finally discovering some tried and true practices that most other companies in the software space learned long ago (hopefully! I may be wrong here, though): “By late October, Mr. Srivastava’s team was beginning to automate the testing that had historically been done by hand.” OK! So Microsoft actually finally discovered the ancient art of test-driven development and automated test cases? Fascinating! As is this discovery: “If a feature had too many bugs, software ‘gates’ rejected it from being used in Longhorn. If engineers had too many outstanding bugs they were tossed in ‘bug jail’ and banned from writing new code.” So Microsoft is finally using automated continuous build environments and a rigorous build procedure? Again - to most of us this should be nothing new. It should perhaps be a little amazing that Microsoft took this long to discover these things. Or, as Bill Gates puts it (as quoted by the WSJ article): “It’s amazing the invention those guys have brought forward, […]“. Yeah! They invented it. Sure. It seems to me like lots of open source development projects have been using these techniques for coordinating complex distributed development efforts. Also, these tools and approaches are detailed in most texts describing the implementation of Agile software development approaches. Should Microsoft be becoming a bit more agile? Nah! Let’s not jump to conclusions here.
A telling insight in the article is that Bill Gates “was concerned that the unproven tools […] would levy a ‘tax’ on engineers — in other words, that they would spend so much time trying to meet Mr. Srivastava’s standards that they wouldn’t be able to devise innovations […]” So what this is telling us is that — at least to Mr. Gates — “innovations” are more important than a stable and maintainable code base. Somehow, this does not sound right. If I can choose between a stable version of the OS and one that brings “innovations” (whatever that may mean — all I can think of is eye candy and bells&whistles), I’ll take the more stable version any day, thank you very much. Even more so if, as in the case of Microsoft Windows, I’m paying good money for it.
Somehow, out of all these basic software engineering issues which it appears that Microsoft could have learned from any good software engineering textbook and the strange and wonderful set of priorities at Microsoft, the one point that astounded me the most was that after a running Windows Vista build had finally been achieved by Christmas, “the group celebrated by not working over the holidays.” Now, I’ve read a lot (some good, some bad) about the dedicated Microsoft developers. But as a manager, I’d do my damndest to make sure that my team doesn’t work over the Christmas holidays. Especially bearing in mind that this is three quarters of a year before the scheduled release date. Maybe — just maybe — that’s why I’m not a manager at MS.
Bookmark on del.icio.us
Add this post to digg.com
Bookmark on reddit.com