Why adding more coders to a late project makes it even later

In 1975, IBM veteran Fred Brooks published The Mythical Man-Month, and its central idea still humbles engineering managers today. It's called Brooks's Law: "Adding manpower to a late software project makes it later." Our intuition says more people means faster work — but software doesn't behave like digging a ditch.

Brooks explained why with the phrase "the man-month is a myth." We love to measure work in person-months (one person working one month), assuming people and time are interchangeable. That only holds when tasks can be perfectly split with no communication between workers. Software is the opposite: tasks are deeply interconnected, so people must constantly coordinate.

Two forces sabotage the new hires. First, ramp-up time: newcomers must learn the codebase before they help, and the veterans who train them stop producing to do it. Second, communication overhead: as a team grows, the number of connections between people explodes roughly with the square of the team size. Ten people have 45 possible communication pairs; double the team and you get 190.

The lesson isn't "never add people." It's that scaling a team has real costs, and a project that's already behind is the worst time to pay them. Better levers exist — cutting scope, improving tools, or splitting work cleanly before the crunch.