Tale Of Two Microsofts: How Does Redmond Develop Software? - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

IoT
IoT
IT Leadership // CIO Insights & Innovation
Commentary
1/20/2009
03:12 PM
Alexander Wolfe
Alexander Wolfe
Commentary
Connect Directly
Facebook
Twitter
RSS
E-Mail
50%
50%

Tale Of Two Microsofts: How Does Redmond Develop Software?

My recent post (a rant, really) "More Than Coding Mistakes At Fault In Bad Software," lamented the lack of well-tempered development practices, particularly as regards PC software, among most programmers. Which leads directly to another can of worms -- namely, how do they do things at Microsoft?

My recent post (a rant, really) "More Than Coding Mistakes At Fault In Bad Software," lamented the lack of well-tempered development practices, particularly as regards PC software, among most programmers. Which leads directly to another can of worms -- namely, how do they do things at Microsoft?According to my sources, there's both a very good side to the software behemoth and a not-so-great component. Here are excerpts from two e-mails I received from people who I've verified worked at Microsoft. (References which could reveal the names of the guilty have been removed.)

The first correspondent gives a highly encouraging report of a thorough approach that's applied toward constructing software:

"I entered Microsoft in 2000. They had a very formal model and set of training required for all new hires. After all, even a small team there is hundreds of people, and I started out in [name of group deleted] which had well over a thousand. There is almost no "seat of pants coding" done there. Every single feature in every product is tied to a customer scenario that was vetted with marketing, specified by a person whose job it is just to specify how those features will work, reviewed by a member of the test organization, and implemented by a developer. Some teams were going even further by the time I left, requiring all high-level features to be signed off on by some of the major customers.

With regards to the process model, I'd characterize it as waterfall-esque: A defined period for requirements gathering and sign-off, an early prototyping phase, an early development phase where the highest-risk items are put together, and then stabilization and build-out phases where things are complete enough to start getting concrete customer feedback.

I won't say it's all peaches and cream. Sometimes things like the early versions of Longhorn slip under the radar because all of the management rigor is focused elsewhere (service packs and shipping Server 2003, in that case). Without real oversight, things go badly quickly. But the company's pretty mature at this point. "

That e-mail was pretty comforting. But then I received this, which paints a darker picture:

"I worked in a build group. This means that we always inherited 90% of our code. I was constantly appalled by the quality of our code. It was written in Perl, and the funny thing was, the build teams were the only people who saw them. The code didn't go outside our group, no one ran it but us and our programmers. It was the perfect place for bad code to fester.

We would be confronted by a bug in a piece of code, and if one ever managed to get a hold of the person who was working on that code at the time it was being written, the response was usually, "We were on a deadline, and just had to get it working. So, we ignored every single good coding practice, in order to make it work as soon as possible."

This pressure didn't stop there, either. I was constantly expected to fix the problem, and move on, and when I came back with what went wrong, and how it has been resolved, and will never happen again, I was confronted with disdain from my boss, because I took too long to do it. He would comment that it wasn't that big a deal, and didn't need a full solution; it just needed the temporary solution that he desired."

Admittedly, this is a small sample from which to extrapolate and make broad-brush assumptions about Microsoft's development practices. Still, both e-mails have the ring of truth. You'd expect that Microsoft's high-level development teams -- the groups which build new products from scratch -- would have their acts together.

At the same time, it's not surprising to hear that bug-fix groups are under pressure to ... fix bugs quickly.

Overall, it's clear that Microsoft has made great strides since the days when it brought in folks like Dave Cutler (hired in 1988 from the late, great Digital Equipment Corp.) to help shape up its development efforts. (Cutler led the creation Windows NT.)

Of course, output trumps input, so the next real test of the effectiveness of Microsoft's processes -- also its biggest test in a decade -- will be Windows 7. From what I've seen so far, it's looking very encouraging. The reaction to Vista must've been a big wake-up call to Redmond, and they seem to have answered the bell.

What's your take? Let me know, by leaving a comment below or e-mailing me directly at [email protected].

Like this blog? Subscribe to its RSS feed, here.

For a mobile experience, follow my daily observations on Twitter.

Check out my tech videos on this YouTube channel.

Alex Wolfe is editor-in-chief of InformationWeek.com.

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Comment  | 
Print  | 
More Insights
Slideshows
Data Science: How the Pandemic Has Affected 10 Popular Jobs
Cynthia Harvey, Freelance Journalist, InformationWeek,  9/9/2020
Commentary
The Growing Security Priority for DevOps and Cloud Migration
Joao-Pierre S. Ruth, Senior Writer,  9/3/2020
Commentary
Dark Side of AI: How to Make Artificial Intelligence Trustworthy
Guest Commentary, Guest Commentary,  9/15/2020
White Papers
Register for InformationWeek Newsletters
Video
Current Issue
IT Automation Transforms Network Management
In this special report we will examine the layers of automation and orchestration in IT operations, and how they can provide high availability and greater scale for modern applications and business demands.
Slideshows
Flash Poll