Software and engineering
Brooks's law
Adding people to a late software project makes it later: the new hands cost training and communication before they add output.
Fred Brooks, The Mythical Man-Month (1975), from managing IBM's OS/360 in 1964 and 1965; reflected on in the 1995 anniversary edition.
The man-month treats people and months as interchangeable, which is only true for work that needs no communication. Brooks's law says that on a late project with communication between its parts, adding people makes it later, for three reasons. The newcomers must be trained, by the people who were producing. The work must be repartitioned, which costs the whole team. And the communication paths grow as n(n - 1) / 2: 5 people have 10 pairs, 10 people have 45, 20 people have 190, so doubling a team of ten roughly quadruples the pairs. Brooks's own case was OS/360, which his 1995 preface describes as late, over its memory budget, several times its cost estimate and slow until several releases in.
Ingo Scholtes, Pavlin Mavrodiev and Frank Schweitzer tested the claim in 2016 on 58 open source projects, more than 580,000 commits by more than 30,000 developers. Output per developer fell as teams grew, a strong Ringelmann effect, and the size of the drop tracked how fast the network of developers editing the same files grew, a rough measure of coordination load. In practice the law shapes the choices when a date slips: cut scope, move the date, or accept that more people will deliver later. If you add people anyway, add them early, in whole teams with a clean partition of the work, and expect the ramp to be paid before it pays back.
The law is scoped and often quoted without its scope. It applies to late projects whose parts must communicate and where people are added mid-stream. Work that partitions cleanly, such as labelling data or translating documentation, does scale with headcount, and a project whose problem is one missing specialist is helped by that specialist. The evidence is also contested: Thomas Maillart and Didier Sornette argue that open source projects show superlinear production, with output per developer rising as teams grow, and the two camps disagree partly about what to count as output. Commit counts are a crude proxy for value. Treat the law as a default to be argued against with numbers, not as a verdict.
Example
In Empirical Software Engineering (published online in December 2015), Ingo Scholtes, Pavlin Mavrodiev and Frank Schweitzer of ETH Zürich analysed the git histories of 58 open source projects, more than 580,000 commits by more than 30,000 developers. They found that productivity per developer declines as team size grows, a strong Ringelmann effect, and that the magnitude of the decline is tied to the growth of the co-editing network, the graph of developers who touch the same files, which they read as a first approximation of coordination requirements. They set this against an earlier claim that open source teams become more productive as they grow and found the opposite in the larger data set.
Where it applies
When a deadline slips, count the pairs before you count the hires: going from 8 to 12 people takes communication paths from 28 to 66. If you must add, add early, add whole teams with their own partition, and budget the ramp. The same arithmetic applies to multi-agent systems: each extra agent that must coordinate with the others adds message traffic that grows faster than the agents.
Think about it
On your current project, how many of the people you would add 'to go faster' would be net positive before the deadline?
Applied it to something real? Log it.
Test yourselfA 10-person project is three weeks late and the manager adds 10 more people. What happens to the communication paths, and why does the project not speed up?
Pairs go from 45 to 190, about four times. The new people need training from the old ones and the extra coordination eats the added capacity, so the project gets later.
Related models
- The planning fallacyPeople predict their own projects will finish sooner and cost less than almost every comparable past project did.
- Conway's lawA system's design copies the communication structure of the organisation that built it, so the org chart is an architecture decision.
- NonlinearityCause and effect are not proportional: a push can do nothing or everything depending on where the system sits relative to a threshold.
- Bottlenecks and the theory of constraintsA system's throughput is set by one constraint; improving anything else is wasted effort until that constraint is fixed.
Sources and further reading
- Frederick P. Brooks, The Mythical Man-Month, Anniversary Edition (Addison-Wesley, 1995), preface and contents (publisher sample)
- Ingo Scholtes, Pavlin Mavrodiev and Frank Schweitzer, From Aristotle to Ringelmann: a large-scale analysis of team productivity and coordination in Open Source Software projects, Empirical Software Engineering 21 (2016)
- Thomas Maillart and Didier Sornette, Aristotle vs. Ringelmann: On Superlinear Production in Open Source Software, arXiv 1608.03608