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.