Brooks' Law
How adding manpower to a late software project makes it later.
2 min read · from UNINTENDED by Mayank Mehta
In the early 1960s, IBM set out to build something that had never been built before: a single operating system that could run on every computer in its new System/360 line. It was called OS/360, and it was, at the time, the most ambitious software project in history.
The engineering challenge was enormous. Hundreds of programmers were assigned to the effort. Deadlines were set. Milestones were planned. And then, as anyone who has ever worked on a large software project could predict, things started to slip.
Management responded the way management always responds. They added more people.
On paper, it made perfect sense. If one hundred programmers couldn't finish in time, surely two hundred could. More hands, more code, faster delivery. The math was straightforward.
In practice, it was a catastrophe.
Every new programmer who joined the project had to learn the system's architecture, its documentation, and its existing code. That meant experienced developers had to stop what they were doing and teach. Every hour spent onboarding was an hour not spent building.
Then there was communication. When ten people work on a project, they need to coordinate with each other. When two hundred people work on a project, the number of possible communication paths doesn't double. It explodes. Meetings multiplied. Memos circulated. Integration problems skyrocketed as different teams built things that didn't fit together. Confusion became the default state.
The project, which was already late, got later.
OS/360 eventually shipped years behind schedule, at a cost of over five hundred million dollars, the equivalent of several billion today. Fred Brooks, the man who ran the project, spent the next decade thinking about what went wrong. In 1975, he published a slim, devastating book called The Mythical Man-Month, which distilled the entire debacle into a single sentence that software engineers still quote fifty years later:
Adding manpower to a late software project makes it later.
The insight is counterintuitive but hard to argue with. Complex, interdependent work can't be divided the way you divide bricks. You can't make a baby in one month by assigning nine women to the job. Some tasks have an irreducible core that resists parallelization, and the overhead of coordination grows faster than the benefit of additional hands.
Brooks' Law has since escaped the world of software and found a home in any domain where managers believe that more people equals more progress. Construction projects. Organizational restructurings. Government programs. The pattern is always the same. A deadline is missed. More resources are thrown at the problem. And the problem, now burdened by the weight of coordination, communication, and confusion, gets worse.