Brooks’s Law

“Adding manpower to a late software project makes it later.” — Fred Brooks, The Mythical Man-Month (1975)

The Claim

You cannot trade people for time in software engineering. Beyond a very low threshold, adding developers to a late project increases the delivery date rather than bringing it in. The obvious intuition — 9 women can’t make a baby in one month — understates the problem. Brooks’s point is sharper: the new people actively slow down the ones already there.

Why It Holds

Three compounding forces:

1. Ramp-up cost. New engineers must learn the codebase, conventions, team dynamics, and problem domain. They produce negative net output for weeks and consume the time of existing engineers who must onboard them — pulling exactly the most productive people off the critical path.
2. Communication overhead scales as n². Each new person adds n-1 new communication edges. Ten people have 45 pairs; twenty people have 190 pairs. The cost of keeping everyone aligned grows quadratically while the work grows linearly.
3. Task indivisibility. Software work is partitionable only in narrow ranges. Some tasks must be done sequentially (you cannot unit-test an API that doesn’t exist yet), and the critical path is not compressible by headcount.

The Mythical Man-Month

The underlying error Brooks identifies is confusing “man” with “month.” Project plans are written in person-months — a unit that assumes effort and time are interchangeable. They are not. You can double the effort by doubling the people, but you cannot halve the time, because the work itself has serial structure and the new people impose costs on the old ones.

Applied to AI-Augmented Engineering

The law’s update for the 2020s: adding LLM agents to a late project may or may not make it later, depending on how the work is structured. LLMs have no ramp-up cost and impose minimal communication overhead on humans if they operate autonomously on well-scoped tasks. But they impose heavy review overhead — every LLM output requires human verification, and that review time is on the critical path. The right reading of Brooks’s Law now: the constraint is not headcount, it’s verified output per unit of senior-engineer attention. See large-language-models and source—karpathy-llm-coding-notes for the atrophy/tenacity framing.

In This Wiki

• Depends on conways-law. Conway explains why adding people is expensive: every new person expands the communication graph, which deforms the architecture. Brooks observed the symptom; Conway explained the mechanism.
• Contrasts with densities-of-excellence. The high-performer clustering effect is the positive case of a related force: when everyone at the table is already world-class, ramp-up is faster and communication is denser and higher-bandwidth. Brooks’s Law strongest when ramp-up is slow and communication is low-quality; weakest at high-density teams.
• Relates to hofstadters-law. Both are about the hidden costs of planning. Hofstadter says projects take longer than you expect; Brooks says the obvious fix (more people) backfires.
• Relates to Kernighan’s Law. Debugging is twice as hard as writing, and debugging by someone unfamiliar with the code is harder still — new engineers often create bugs the original team must debug.

Escape Hatches

Brooks notes the law is not absolute. Adding people works when:

• The project is early enough that the new hires can ramp up before the critical path needs them.
• The work is genuinely parallelisable (independent features, test coverage, documentation).
• The new people are senior enough to reduce communication cost by making independent decisions.

Otherwise, the response to “project is late” should be reduce scope, not add people — the only lever that moves the delivery date toward you.

Sources

• source—laws-of-software-engineering — in the Teams cluster.
• Fred Brooks, The Mythical Man-Month (1975, 20th anniversary ed. 1995).