# Brooks's law

> Adding people to a late software project makes it later, because new people cost time before they save any.

Concept · Laws of software engineering · https://levelcode.org/concepts/brooks-law

**Brooks's law** says that adding manpower to a late software project makes it later. Fred Brooks stated it in *The Mythical Man-Month* (1975), drawn from his experience managing IBM's OS/360. The book's title is the point: people and months are not interchangeable.

## How it works

Three costs arrive the moment you add someone:

- **Ramp-up.** A new person needs weeks to learn the code, the tools and the domain. Someone on the team has to teach them, so the team slows down before the newcomer speeds anything up.
- **Communication.** With *n* people there are *n*(*n* − 1)/2 possible pairs who might need to coordinate. Going from 5 to 10 people takes you from 10 pairs to 45.
- **Indivisible work.** Some tasks can't be split. Nine people can't make a baby in one month, and nine engineers can't debug one race condition nine times faster.

On a project that is already late, the remaining time is short, so the ramp-up cost can easily eat all of it.

> [!NOTE]
> **Where it breaks down.** Brooks himself later called the law an oversimplification. Whether extra people help depends on details the slogan ignores. Adding people **early** in a project, when there's time to ramp up, often helps. Adding people who **already know the codebase**, say from a neighboring team, costs much less. Adding them to **separable work** with clear boundaries (a new client app on a stable API, a test suite, a migration script) avoids most of the coordination. The communication math assumes everyone talks to everyone; a team split along good [boundaries](https://levelcode.org/concepts/conways-law) doesn't. Read it as "people have a ramp-up cost that late projects can't afford", not as a rule that headcount never helps.

## What to do instead

- **Cut scope first.** Removing a feature is the fastest way to bring a date in.
- **If you add people, give them separable work** and a named person to ask, rather than spreading them across the hardest problems.
- **Protect the critical path.** Keep the people who know the hard parts focused on them, and move everything else away from them.
- **Re-plan honestly.** A project late once is usually late because the [estimate](https://levelcode.org/concepts/hofstadters-law) was wrong, not because the team was small.