Layers

An interesting discussion is taking place about Windows Vista, the successor to Windows XP coming out Thursday.

Joel Spolsky (who always has excellent articles) picks some nits about the development process at Microsoft, zeroing in on the Shutdown options as an example. Joel counts nine options on the Start Menu, plus as many as six more on the computer itself, for shutting down and says this is way too many.

The more choices you give people, the harder it is for them to choose, and the unhappier they'll feel. See, for example, Barry Schwartz's book, The Paradox of Choice. Let me quote from the Publishers Weekly review: “Schwartz, drawing extensively on his own work in the social sciences, shows that a bewildering array of choices floods our exhausted brains, ultimately restricting instead of freeing us. We normally assume in America that more options ('easy fit' or 'relaxed fit'?) will make us happier, but Schwartz shows the opposite is true, arguing that having all these choices actually goes so far as to erode our psychological well-being.”

The fact that you have to choose between nine different ways of turning off your computer every time just on the start menu, not to mention the choice of hitting the physical on/off button or closing the laptop lid, produces just a little bit of unhappiness every time.

HeThe more choices you give people, the harder it is for them to choose, and the unhappier they'll feel. goes on to systematically reduce these options to just one, a “b’bye” button that logs you out, locks the keyboard and starts writing the RAM out to non-volatile storage. If nobody else logs in within 30 seconds, the computer would go into “sleep” mode to conserve power. If no activity for a longer time, it could physically power down. If the power is removed, all the information is already saved to un-Hibernate.

Side note: I really like the idea of using a Hybrid drive, or even just an internal thumb-drive for storage of memory during a suspend. Why didn’t I think of that? Spolsky suggests that the OS could even write memory state to this non-volatile storage in the background, so that a “b’bye” could complete faster.

Side note 2: I saw one well-spoken counterpoint to this idea in the discussion on Slashdot.

This seems like basic design. Make it simple to do common stuff. Make it possible but not as easy to do things that you do less often (more advanced).

Moishe Lettvin, a Microsoft developer in the "Mobile Experience" team, was an integral part of the development of the Shutdown menu. Lettvin saw Spolsky’s article and spoke out on his own blog, revealing how intensely bureaucratic Microsoft has become.

His team consisted of eight people, only one of whom (himself) was a developer. In order to make decisions, they had to interact with two other teams (shell and kernel) with about eight members each who were relevant to Lettvin’s team’s mission. None of these 24 people had final say in how the feature should work. When those teams couldn’t reach consensus, they had to climb six layers up the org chart before they had a manager in common to make a decision. Including these levels of management, about 43 people had a voice in the final outcome of this feature.

Lettvin’s team of 8 people met every week, sometimes including people from the other teams. His Project Manager met more frequently in order to coordinate with the other two teams, since that is what PMs do — go to meetings so developers don’t have to.

And that’s just the human layers.

[Source code control for] 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.

According to Lettvin’s account, about every four weeks his team would find out that one of the other two teams had made some decision or change which would require changes in their own project. Trying to compensate for those external changes would take about 90 minutes out of the weekly meetings for about 4 weeks. That’s 8*1.5*4 = 96 man-hours of discussion per month just in meetings, plus however much time each person spent during the week working on the problem, all because another team made a change in a vacuum. Then, when the code was written and QA’d and documented and committed to the source-code control, it might take up to six months before that code would be tested against changes committed by the other two teams, by which time all three teams would have created another six months of development.

Lines of code is a very common metric for developers. There are plenty of different standards out there, depending on your development process and how you measure “lines of code”. One well-accepted standard calls for 20 lines of finished code per developer per day. That doesn’t sound like much, until you consider that testing and rewrites are factored into this calculation. If you write 100 lines of code in a day, you expect that about 80 of those lines will require changes before they become final.

During the year Lettvin worked at Microsoft, he produced about 200 lines of code. That’s about 0.8 lines of code per day. I’m sure rewrites accounted for a lot of this - even Microsoft can’t afford to keep (many) people around not doing anything. Apparently, they can still afford to have people working in so much isolation that a majority of their productive work is in vain. And gratuitious use of meetings is clearly part of the master plan.

I have to say, the fact that Vista is being released at all sound like nothing short of a miracle. I can’t imagine that Microsoft can keep this up much longer. Neither can some other people.

Every single organization seems to follow this exact same path. Lean and mean at first, to fast and nimble second, to large but feature, to slow and bloated. The next step after this tends to be, jump at any and all projects to see if anything will stick progressing slowly down a spiral with a large change either acquisition by another company or dramatic slashing of middle-management workers and projects to focus on their core. Unfortunately I have yet to see a large organization that doesn't seem to go down something similar to this path.

That Microsoft has been able to avoid Stage 4 at all is a reflection of their success, but I think, like most empires, Microsoft will need to reinvent itself or face irrelevance.

[via Joel on Software]

Related posts: Firefox 2.0, Do the shuffle