November 27th, 2006
How would you fix Microsoft's Windows-development problems?
By now, everyone’s heard Microsoft’s CEO Steve Ballmer’s repeated pronouncement that Microsoft will never again take five years to deliver a new version of Windows. But no one inside or outside seems to know exactly how Microsoft plans to make the Windows development process more agile.
Many folks have ideas, however, as to how Microsoft can fix the myriad management and technical setbacks that resulted in Windows Vista looking little like the product based on initial “Longhorn” expectations. And they’re offering freely their two cents about what ails Windows and how to remedy the problems to Steven Sinofsky (Senior Vice President of Windows and Windows Live engineering) and his band of merry Windows developers.
Joel “on Software” Spolsky kicked things off last week when he posted about his dissatisfaction with the “Off” button in Windows Vista. Spolsky said:
"I'm sure there's a whole team of UI designers, programmers, and testers who worked very hard on the OFF button in Windows Vista, but seriously, is this the best you could come up with?"
Channeling Mini-Microsoft, Spolsky continued:
"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. The only way Microsoft has managed to hire so many people has been by lowering their hiring standards significantly."
Spolsky subsequently linked to Moishe Lettvin, a Google software engineer and former Windows developer who worked on the aforementioned Vista Off button. Lettvin details exactly why it took 40+ individuals more than a year to deliver the final Vista Off button:
"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."
(Word on the street is Sinofsky is taking a chainsaw to the Windows organization any day now. By the time all of the expected post-RTM Windows defections and cuts are done, Microsoft might have eliminated quite a bit of the middle-management bloat that seems to have been a big part of Vista’s problems.)
The maze of Windows dependencies mentioned by Lettvin – and former Windows chief Jim Allchin when I spoke with him last month – is another thorny issue that needs solving in order for the Windows trains to run more on time.
Allchin said that the Vista team made considerable headway in mapping out the Windows dependencies (and showed off a two-story-high, floor-to-ceiling dependencies map on the wall of Building 27 as evidence) in a way that would simplify Windows development going forward.
An anonymous poster, claiming to be a Windows veteran, posted some more ideas for reducing Windows dependencies in the comments of Lettvin’s blog post.
"There are three obvious solutions to this (Windows dependency) problem: 1. federate out the source tree, and pay the forward and reverse integration taxes (primarily delay in finding build breaks), or… 2. remove a large number of the unnecessary dependencies between the various parts of Windows, especially the circular dependencies. 3. Both 1&2"
The poster said option 1 was the winning solution “in large part because it could be executed by a small team over a defined period of time. #2 would have required herding all the Windows developers (and PMs, managers, UI designers…), and is potentially an unbounded problem."
While some Microsoft watchers seem to think Microsoft won’t be able to get a piece of software as big and complex as Windows on the faster (or at least, faster) track, I actually think the Redmondians can do it. Sinofsky mastered the art of delivering a new version of Office like clock-work, every two years. How did he pull this off? He never bit off too big a bite in any one release.
I predict we’ll see more incremental, smaller-bang Windows versions, going forward. Industry-changing promises, ambitious feature sets and revolutionary releases is over for the Windows team. In the new world order, if and when Microsoft wants to deliver radically new — and potentially risky — Windows functionality, it can simply add the technology in the form of a Windows Live add-on.
Anyone else see other ways Sinofsky and Co. can make the Windows team more agile?
Mary Jo has covered the tech industry for more than 20 years. Don't miss a single post. Subscribe via Email or
RSS. You can also follow Mary Jo on Twitter.
Got a tip? Send Mary Jo your rants, rumors, tips and tattles. For disclosure on Mary Jo's industry affiliations, click here or to see Mary Jo's full profile click here.
