The Mythical Man-Month
Why adding people to a late software project makes it later.
Summary
Brooks managed the development of IBM's OS/360, one of the largest software projects of the 1960s, and wrote these essays about why it went as it did. The central proposition, now called Brooks' law, is that adding manpower to a late software project makes it later, because the new people must be trained by the existing ones and because communication paths grow as the square of team size.
The conceptual integrity argument is the book's other main contribution. Brooks holds that a system must proceed from a single mind or a small number of agreeing minds, that consistency of design matters more than the sum of good individual ideas, and that this requires separating architecture from implementation. He advocates the surgical team structure, in which one person does the design and others support.
Other essays cover the second system effect, in which an architect's second project accumulates all the features omitted from the first and becomes bloated; the argument that a programmer should plan to throw the first version away because they will anyway; the observation that scheduling is where most projects fail and that estimates are compressed by the desire to meet a date; and the recommendation to document design decisions formally.
The twentieth anniversary edition adds No Silver Bullet, in which Brooks argues that no single development produces an order of magnitude improvement in software productivity, because the essential difficulty is the complexity of the problem rather than the accidental difficulty of the tools. The examples are from 1960s mainframe development and much of the technical context is gone. Brooks himself retracted some positions, including on the surgical team. The law about late projects and the conceptual integrity argument remain accurate.
Key takeaways 8
- Adding people to a late software project makes it later, because of the training burden and because communication paths grow as the square of team size.
- Conceptual integrity is the most important property of a system and requires that the design come from one mind or a few agreeing minds.
- Architecture must be separated from implementation, because a design produced by committee acquires inconsistencies that no amount of implementation quality corrects.
- The second system an architect designs is the most dangerous, because it accumulates every feature omitted from the first.
- The first version of any system will be thrown away, so a team should plan for that rather than pretend otherwise.
- Schedule slippage happens one day at a time rather than in catastrophes, which is why it is not noticed until it is unrecoverable.
- The essential complexity of software comes from the problem being solved rather than from the tools, which is why no tooling improvement produces an order of magnitude gain.
- Building a system that works is fundamentally different from building a product, and the effort is roughly nine times greater for a supported product than for a working program.
Who should read it
Anyone managing software projects who wants the original statement of why adding people fails and why design consistency matters more than individual quality.
Where it sits in the reference 2
Who recommended it 6 · 2 direct
Similar books 6
Chosen by shared topics, the entries that hold them, and the people who recommended both.
