Microsoft's Vista experience offers developers a lesson |
 |
By Brian Eastwood, Site Editor
28 Nov 2006 | SearchVB.com |
|
|
For years now bloggers large and small have filled the Web with theories explaining Windows Vista's many delays. Some theories focus on outside pressures, such as the need to beef up security or comply with antitrust measures, while others blame the company's burgeoning bureaucracy.
|
|
|
|
|
The end result of all this is what finally shipped: the lowest common denominator, the simplest and least controversial option.
Moishe Lettvin
former developer, Microsoft
|
|
|
|
|
|
|
|
|
|
On the eve of the operating system's formal unveiling, a former Microsoft developer has shed some light on just how large that bureaucracy was and how it affected his entire team's productivity. His experience provides a valuable lesson for developers -- the more layers of complexity in a project, the longer it takes and the worse it looks in the end.
In a blog post entitled The Windows Shutdown crapfest, Moishe Lettvin, formerly of the Windows Mobile PC User Experience group, describes how there were at least 40 people "with a voice" in how the shutdown menu looked.
What should have taken a week took a whole year -- a year in which Lettvin estimates he wrote "a couple hundred lines, tops" of code -- and left a lot to be desired.
"The end result of all this is what finally shipped: the lowest common denominator, the simplest and least controversial option," wrote Lettvin, who now works for Google. (Joel Spolsky took on the finished product in his blog post, Choices = Headaches: "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.")
How did a team of such smart developers produce such an ill-conceived menu? Lettvin's anecdotes explain why.
- Lettvin's Windows Mobile PC User Experience team was in the Tablet PC group, the manager of which was several steps up the organizational chart from Lettvin. There was also a core Windows Shell team, which "had a charter of [its] own which may or may not have intersected ours."
- The mobile PC team had to align its feature with the work of the Windows Shell team, which was working on the rest of the Start menu, and with the kernel team, which was working on the functionality for the shutdown UI. Just when his team had finished part of its project, Lettvin said, the shell and kernel teams would report that they had changes to make. This happened numerous times.
- Given the size of Windows Vista as a whole, there was no central code repository, nor were there daily builds. Instead, there was a tree of repositories, where developers checked their code into nodes that were periodically up and down the hierarchy. "[I]t 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," Lettvin wrote. "[E]ach team had no idea what the other team was actually doing until it had been done for weeks."
|
| More Vista controversy |
Visual Studio vs. Vista: What's going on here?
When Microsoft released the long-awaited VS 2005 Service Pack 1, it revealed that Vista won't support older versions of Visual Studio and will even have issues with VS 2005. In other words, MS erred badly, Mike Gunderloy writes.
WinFS release called off
WinFS Beta 2 has been cancelled, and the technology is now slated to be bundled into the next SQL Server release -- far short of the original spot for WinFS in Vista. |
|
|
|
|
The scale and scope of Windows Vista means that Lettvin's story is likely one few developers will ever encounter. Even within Microsoft, where open and flexible development has caught on for ASP.NET AJAX, the Live suite and the Xbox, it may be an anomaly. Nonetheless, his experience does offer a few lessons and words of caution.
For starters, make sure everyone is on the same page. A charter or mission statement will serve as a constant reminder of what you're trying to do in the first place. In addition, make sure everyone knows the workflow for the entire project -- and knows where to look to see if it has changed.
If your team is large, and responsibilities are divided, make collaboration a constant process, not just one that occurs in meetings. Set specific deadlines for each step of the process -- modeling, design, testing, quality assurance and so on -- and establish policies for checking in code.
Admittedly, such suggestion sound a bit bureaucratic. The ultimate aim, though, is to establish a procedure that makes sense to developers and contributes to a project's progress instead of hindering it. Lettvin's story seems to indicate that Microsoft did not learn this lesson.
|
|
|
|
