Having just switched back to Windows after 13 years on Mac, this bit of #oldgold from 2006 feels highly relevant. As a response to a Joel on Software post about UI design gone bad, Moishe Lettvin shares a behind the scenes look at how Windows Vista ended up with all of the following options for logging out and shutting down your computer: Switch User, Log Off, Lock, Restart, Sleep, Hibernate, and Shut Down.
While it’s commonplace to shit on Windows and say “LOL look how dumb they is”, I think this post better serves as a harrowing tale about large software projects, cross-departmental features, and stakeholder burden.
Good User Experience expects consistency. And because UX sits on the upper crust (the interactive visual layer) of software, any time you seek to improve consistency and User Experience on a large website or piece of software, you inevitably start stepping on the toes of into other teams’ projects. Going cross-department is where things get tricky.
In order to roll out a new Shutdown menu, Lettvin’s Windows Mobile PC User Experience team of ~8 people had to talk with the Windows Shell team of ~8 people who had to involve the Windows Kernel team of ~8 people. Those cross-departmental meetings meant you needed to get managers involved, and their managers’ managers, and their managers’ managers’ managers. The stakeholder burden begins piling up.
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 19 was somebody who did have final say but who that was I have no idea…
According to Brook’s Law that’s 903 nodes of communcation! I think anyone who has worked on a large team or cross-departmental project like a Design System or Styleguide knows this pain well. Meetings end with “I can’t make that call”, so you spend the next week tracking down the person who can make that call. Or you uncover one person who will be very upset if you remove one tiny unused link or tracking script. Or some other unknown department was working on the same thing and has ahem different ahem opinions.
The weird possessive nature of developers regarding their code seeps out. Layers of management and stakeholders disconnected from the code heap down decisions and requirements without understanding the underlying quality and capabilities. And to top it all off, it could be weeks until you see or hear about what others are doing…
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.
As I read this, consensus-driven software makes people happy but risks sub-par results. But at its core, large software projects are the product of humans working together. Some say they even inherit our biases.
Since this is a human problem, not a software problem, it seems effective communication and transparent sharing could go a long way in solving some of these issues. It’s an interseting problem though. I think as I’ve gotten older, I’ve become more interested in the people problems of Web Design. These tend to be harder, more gory, and more complex than the technical problems.