Software developer Joel Spolsky wrote a very interesting article on how ridiculous the user interface for shutting down your PC is under Windows Vista:

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?

Every time you want to leave your computer, you have to choose between nine, count them, nine options: two icons and seven menu items. The two icons, I think, are shortcuts to menu items. I’m guessing the lock icon does the same thing as the lock menu item, but I’m not sure which menu item the on/off icon corresponds to.

On many laptops, there are also four FN+Key combinations to power off, hibernate, sleep, etc. That brings us up to 13 choices, and, oh, yeah, there’s an on-off button, 14, and you can close the lid, 15. A total of fifteen different ways to shut down a laptop that you’re expected to choose from.

He goes on to suggest possible ways this could have been simplified right down to a single button, though I have to admit I’m not sure what’s wrong with the way Windows XP handles things already with two icons on the start menu—Log Off and Shut Down—which provide you with a few additional options when you click on them. Two clicks, tops, and you’re done.

Anyway, the article is particularly interesting because it prompted a former Microsoft programmer who worked on that very feature by the name of Moishe Lettvin to write up a blog entry in which he explains how working on this rather small bit of code required a small army to implement:

So just on my team, these are the people who came to every single planning meeting about this feature:

• 1 program manager
• 1 developer
• 1 developer lead
• 2 testers
• 1 test lead
• 1 UI designer
• 1 user experience expert
• --
• 8 people total

These planning meetings happened every week, for the entire year I worked on Windows.

In addition to the above, we had dependencies on the shell team (the guys who wrote, designed and tested the rest of the Start menu), and on the kernel team (who promised to deliver functionality to make our shutdown UI as clean and simple as we wanted it). The relevant part of the shell team was about the same size as our team, as was the relevant part of kernel team.

So that nets us a conservative estimate of 24 people involved in this feature. Also each team of 8 was separated by 6 layers of management from the leads, so let’s add them in too, giving us 24 + (6 * 3) + 1 (the shared manager) 43 total people with a voice in this feature. Twenty-four of them were connected sorta closely to the code, and of those twenty four there were exactly zero with final say in how the feature worked. Somewhere in those other 17 was somebody who did have final say but who that was I have no idea since when I left the team—after a year—there was still no decision about exactly how this feature would work.

By the way “feature” is much too strong a word; a better description would be “menu”. Really. By the time I left the team the total code that I’d written for this “feature” was a couple hundred lines, tops.

But here’s how the design process 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.

You think that’s impressive, go read about the central code repository system Microsoft uses for an even better understanding of why it took so long to develop Vista. This prompted Joel to follow up with another comment on Microsoft’s problem:

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. In the early nineties Microsoft looked at IBM, especially the bloated OS/2 team, as a case study of what not to do; somehow in the fifteen year period from 1991 - 2006 they became the bloated monster that takes five years to ship an incoherent upgrade to their flagship product.

I’ve played around a bit with the Release Candidate of Vista and I have to admit that the new shutdown interface left me perplexed for a moment or two until I figured out where the hell the menu was and the overall experience left me wondering why it took 6 years to develop Vista. There’s certainly improvement in many parts of Vista, but there’s also plenty that could be improved upon and given the time it took to put together you’re left feeling like it should be a helluva lot better rather than just somewhat better in certain areas. Now I know why I had that feeling.

In the long run it may turn out that the biggest obstacle to Microsoft’s continued dominance of the OS market may come from within Microsoft itself. If the development process continues in this vein then the length of time between new OSes will only grow and that will open up opportunities for someone else to hit on an innovation that makes switching away not such a crazy idea.