One of the dullest low-level tasks in creating software at Microsoft is managing “the daily build,” which is, in practice, a daily prototype of the product in process. The person performing the daily build collects all the code from the programmers on the product team and puts it on a single computer to see if it all works together. For years, this task was performed by an entry-level person and regarded as mind-numbing grunt work. One manager changed that in a way that made the process more efficient and more effective. Instead of delegating the task to a grunt, the manager gave the daily-build responsibilities to the people writing the code. Each day the programmers would give their code to one “buildmeister,” who put it all together. If the code wasn’t compatible, the person whose software “broke the build” became buildmeister as punishment until someone else’s code broke the build. In the summer of 1996, the buildmeister was also given an enormous zucchini — “the zucchini of questionable freshness,” — sometimes with Groucho Marx glasses and a fake nose, to keep until the next buildmeister was named.
Delegating the task of buildmesiter to the team changed Microsoft’s daily prototyping process for the better. More developers got to see how their work fit together, or didn’t. No one wanted to be buildmeister, so an extra incentive to hand in quality code was created. What’s more, the unpleasant task of build management was equitably shared by everyone in the group. Accountability, responsibility, and quality were thus aligned.
The realignment had other important repercussions. The smartest and savviest high-level software developers hated being buildmeisters and wanted to spend as little time on the task as possible. But instead of weaseling out, they wrote tools to automate the task of buildmeister. The result? Microsoft developrs now manage the build with a fraction of the friction and in a fraction of the time they did in the mid-1990s.