Brooks's law states that adding manpower to a late software project makes it later. It was articulated by Fred Brooks in his 1975 book The Mythical Man-Month, based on his experience managing the development of OS/360 at IBM.

The reason is that new team members are not immediately productive. They need time to understand the codebase, the domain, and the team's conventions. During that ramp-up period they consume the time of the experienced members who have to train and answer questions. For a short stretch, the project capacity actually decreases before it recovers.

There is also the communication overhead problem. If a team has $n$ people, there are $n(n-1)/2$ potential communication channels. Doubling the team does not double productivity; it more than doubles the coordination cost.

Brooks's law is a heuristic, not a theorem. It applies most strongly to projects where tasks are tightly interdependent and the work cannot be cleanly partitioned. Adding people to a late project that is blocked on a single critical path does not help regardless; adding people to a well-partitioned project where independent modules can be parallelised can help, but only after the ramp-up cost is paid.

The practical lesson is to treat late software projects by reducing scope, not by adding people — at least in the short term.