Tale Of Two Microsofts: How Does Redmond Develop Software?Tale Of Two Microsofts: How Does Redmond Develop 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. "

"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."