How Broken is Microsoft?

Microsoft's stock (MSFT) has had a tremendous run since mid-June, rising from about $22 to over $29 now (chart here). Despite MSN's market share losses and the impending flop of Zune, Microsoft's other businesses look good. Most critically, the Vista rollout is nearing, proving that Microsoft's core competency -- its ability to upgrade and enhance Windows -- is still intact. But is that really correct? Look at this:

Moishe Lettvin, a software engineer for Google who previously worked for Microsoft, just revealed how broken Microsoft's software development processes are. Mr. Lettvin spent a year designing the Off menu for Vista. The design of the Off menu, he reports, took a full-time team of 8 people, with wider involvement from another 16, and a total of 43 "with a voice in this feature". Here's his description of how the team worked:

...approximately every 4 weeks, at our weekly meeting, our PM would say, "the shell team disagrees with how this looks/feels/works" and/or "the kernel team has decided to include/not include some functionality which lets us/prevents us from doing this particular thing". And then in our weekly meeting we'd spent approximately 90 minutes discussing how our feature -- er, menu -- should look based on this "new" information. Then at our next weekly meeting we'd spend another 90 minutes arguing about the design, then at the next weekly meeting we'd do the same, and at the next weekly meeting we'd agree on something... just in time to get some other missing piece of information from the shell or kernel team, and start the whole process again.

I'd also like to sketch out how actual coding -- what there is of it -- works on the Windows team.

In small programming projects, there's a central repository of code. Builds are produced, generally daily, from this central repository. Programmers add their changes to this central repository as they go, so the daily build is a pretty good snapshot of the current state of the product.

In Windows, this model breaks down simply because there are far too many developers to access one central repository -- among other problems, the infrastructure just won't support it. So Windows has a tree of repositories: developers check in to the nodes, and periodically the changes in the nodes are integrated up one level in the hierarchy. At a different periodicity, changes are integrated down the tree from the root to the nodes. In Windows, the node I was working on was 4 levels removed from the root. The periodicity of integration decayed exponentially and unpredictably as you approached the root so it ended up that it took between 1 and 3 months for my code to get to the root node, and some multiple of that for it to reach the other nodes. It should be noted too that the only common ancestor that my team, the shell team, and the kernel team shared was the root.

So in addition to the above problems with decision-making, each team had no idea what the other team was actually doing until it had been done for weeks.

The end result of all this is what finally shipped: the lowest common denominator, the simplest and least controversial option.

Joel Spolsky, another programmer (unaffiliated with Microsoft or Google) comments on this:

Every piece of evidence I've heard from developers inside Microsoft supports my theory that the company has become completely tangled up in bureaucracy, layers of management, meetings ad infinitum, and overstaffing.

Value investors who hold Microsoft stock -- be careful!