The Mythical Man Month is another of my favorite books on software and team productivity (this wikipedia page briefly covers the key ideas).
The Mythical Man Month is a classic book which has profoundly affected thinking about software development processes. Written by Fred Brooks, it is based on his management of the IBM System 360 series of computers. This was a large software project (hundreds of developers), and some of his observations are most applicable to projects which are large, or of long duration.
The Mythical Month
The mythical man month is one of the key concepts in the book: progress on a software project will not scale linearly with the staff count, and may in some cases may have an inverse relation (adding people to a late project can cause it to fall further behind).
Brooks doesn’t simply toss this out as a hypothesis; he backs it up with analysis and examples.
Task Partitioning
Some of the ideas he introduces are gems for their concise and memorable nature. Regarding the impact of intercommunication on the mythical man month:
Men and months are only interchangeable commodities only when a task can be partitioned among many workers with no communication between them. This is true of reaping wheat or picking cotton; it is not even approximately true of systems programming.
and this classic observation on the sequential nature of certain tasks:
When a task cannot be partitioned because of sequential constraints, the application of more effort has no effect on the schedule. The bearing of a child takes nine months, no matter how many women are assigned.
Runny Omelets
One of my favorites is this analogy on the sense of urgency being independent of the actual time required:
Observe that for the programmer, as for the chef, the urgency of the patron may govern the scheduled completion of the task, but it cannot govern the actual completion. An omelet, promised in two minutes, may appear to be progressing nicely. But when it has not set in two minutes, the customer has two choices – wait or eat it raw […]
The cook has another choice; he can turn up the heat. The result is often an omelet that nothing can save – burned in one part, raw in another.
(That is, don’t be surprised by the result if you don’t know much about cooking and impose unreasonable demands on the chef.)
Summary
Some caveats. The book has a relative focus on observations from large software projects. Some of the core ideas may not apply directly to your Web-2.0-rapid-prototyping-team-of-3-people. The technological references are, of course, often dated – the book was originally published in the in mid-1970s. The book has an academic feel to it (heavier on deep analysis than lightweight advice).
However the essentials remain relevant three decades later, and I highly recommend the book.
