Brooks' law

Adding manpower to a late software project makes it later.

Fred Brooks gave software its best-known schedule warning in The Mythical Man-Month. Wikipedia’s article on Brooks’s law pulls the quote and context from the book. Brooks called that sentence an outrageous oversimplification that still matches a lot of real projects.

You pay several prices when you add people to a team that is already on a tight timeline:

• Onboarding. New people need context before their commits help net progress. While they learn, veterans answer questions instead of closing gaps.
• Coordination. Everyone on one problem has to stay aligned. With n engineers there are n(n-1)/2 pairwise ties, so sync work jumps when headcount jumps.
• Partition limits. Some jobs do not split across workers the way cleaning rooms does. Brooks used the image of nine women not making a baby in one month to stress that point in The Mythical Man-Month.

Together those forces are why the short-term trend is often backward.

Staffing sometimes helps when the situation meets certain criteria. If the timeline was never real, fixing the plan beats debating headcount. If work breaks into loose pieces with crisp interfaces, extra hands can land without everyone fighting the same merge queue. Adding people early enough that the calendar absorbs ramp-up and meeting tax is a different bet than a rescue hire right before a hard date. Brooks later named what we now call Conway’s law in that book. Martin Fowler’s Conway’s Law bliki is still a compact practitioner’s read. Structure and human communication do not decouple just because the hardware got smaller.

I treat Brooks’ law as more of a warning than a principle to always follow. What helps depends on how coupled the work is, how wrong the schedule was, and whether you gain calendar time or only headcount on paper. When in doubt, assume teaching and coordination will eat the next sprint whole.