The Mythical Man-Month

The model

Fred Brooks managed the development of IBM’s System/360 family of computers and then of its operating system, OS/360, in the 1960s. OS/360 was one of the largest software projects ever attempted at that time, and it was late and over budget. Brooks left IBM to found the computer science department at the University of North Carolina, and in 1975 he published The Mythical Man-Month, a set of essays on what he had learned. It became one of the most cited books in software engineering. He received the Turing Award in 1999 and died in 2022.

The model begins with the title’s unit of measure. Project managers estimate work in man-months, as if people and months could be exchanged: a task of twelve man-months could be done by one person in a year or by twelve in a month. Brooks argues that this is true only for work that can be divided with no need for communication, like harvesting a field. Software is not like that. Each new person must be trained, and each pair of people who must coordinate adds a channel of communication. With n people, there are n(n−1)/2 possible channels, so communication effort grows much faster than the team. Some tasks also cannot be divided at all; as Brooks puts it, bearing a child takes nine months no matter how many women are assigned.

From this comes the book’s most famous claim, now called Brooks’s law: adding manpower to a late software project makes it later. The new people need training from the people already doing the work, and they add communication overhead.

The second pillar is conceptual integrity. Brooks argues that the most important property of a system is that its design reflects one coherent set of ideas. A system designed by many people with independent ideas will be inconsistent, harder to learn and harder to use. Conceptual integrity requires that the design come from one mind, or a very small number of minds working closely together. He compares it to European cathedrals, many of which show the clash of styles of successive builders, against Reims, whose builders over generations subordinated their own ideas to the original design.

Seeing with it

From these two ideas Brooks derives much practical advice.

The surgical team. Following a proposal by Harlan Mills, he suggests organising programming like surgery: a chief programmer who does the critical design and coding, supported by a team of specialists, such as a copilot, a toolsmith, a tester and an administrator. The structure preserves conceptual integrity while giving one mind the help of many hands.

Architecture separate from implementation. The architect defines what the system does, as seen by the user; implementers decide how. Separating the roles lets many people build while a few keep the design coherent.

The second-system effect. A designer’s second system is the most dangerous, Brooks warns, because the designer adds every idea saved up from the first, producing an overloaded design.

Plan the communication. Brooks recommends formal documents, a project workbook, and regular meetings to keep everyone informed, recognising that communication is the core of the work.

Estimate honestly. He notes that programmers are optimists, and that the testing and integration phases are routinely underestimated. His rule of thumb gave a third of the schedule to planning, a sixth to coding and half to testing.

The model also anticipates Conway’s law, the observation by Melvin Conway in 1968 that systems mirror the communication structures of the organisations that design them. Brooks cited Conway and agreed. The site’s idea page Organisations Ship Their Own Shape follows that thread.

Where the model stops

Brooks revised some of his advice in the anniversary edition of 1995, which added four chapters. The most notable change concerns his recommendation to “plan to throw one away”, building a pilot system to learn from before building the real one. Brooks wrote that this advice had assumed the waterfall model, in which a project proceeds through fixed stages, and that he now preferred incremental development, growing a system in stages, each one working, rather than building it all at once. He also reconsidered parts of his view on information hiding, conceding that David Parnas had been right to limit what each programmer needs to know about others’ code.

The anniversary edition also reprinted his 1986 essay “No Silver Bullet”, which argued that no single technique would produce an order-of-magnitude improvement in software productivity within a decade, because most of the difficulty is essential, in the complexity of the problem itself, rather than accidental, in the tools.

Since it was published

Brooks’s law remains widely cited, and studies of software projects generally support its core, though researchers have noted that adding people early, or to well-divided tasks, can help. Agile methods, with their small teams, short cycles and working increments, can be seen as a response to the problems Brooks described. The rise of artificial intelligence tools in software has renewed the debate he began in “No Silver Bullet” about whether a new technology can finally change the economics of programming, and his distinction between essential and accidental complexity is often invoked in it. The site’s essay Every Programming Language Is a Theory of the Programmer takes up some of the same history.

Questions it lets you ask

If we add people now, how long will it take them to become productive, and who will train them? How many people must talk to each other to get this done? Whose mind holds the design, and is it coherent? Is this our second system, and are we adding too much? How much of our schedule is reserved for testing and integration? And is the difficulty we face essential to the problem, or accidental to our tools?