Adding manpower to a late software project makes it later.
What is Brooks’s law?
Brooks’s law is the ultimate reality check for every manager who believes that “more” always equals “faster.” It exposes the mathematical fallacy of the “man-month.” Brooks observed that if a project is sliding toward a deadline, throwing ten new engineers into the fray doesn’t provide a boost; it provides a massive, high-octane distraction. Between the time spent training the newcomers and the exponential explosion of “who needs to talk to whom,” the original team ends up spending more time explaining the work than actually doing it.
The law was coined by Fred Brooks in his 1975 classic, The Mythical Man-Month, a book that remains as painfully relevant today as it was in the era of mainframe computers. Brooks’s central thesis — and the perfect discussion point for you, dear Lex Nunc reader — is that software development is an “interdependent” task. Unlike picking apples, where doubling the workers doubles the harvest, building a digital system is more like a delicate legal negotiation. You cannot simply divide the labor without multiplying the complexity of the communication.
To see how this law has aged in the era of Silicon Valley sprints, look at The Phoenix Project by Gene Kim, Kevin Behr, and George Spafford. This business novel illustrates Brooks’s Law in action within a modern IT department, showing how “work in progress” and “communication overhead” are the silent killers of productivity. For a deeper psychological dive into why we keep making this mistake, Daniel Kahneman’s Thinking, Fast and Slow provides the “Planning Fallacy” framework, explaining our hardwired human inability to accurately estimate how long a complex task will actually take, regardless of how many people we throw at it.
Sidebar
The communication overhead tax
Why exactly does adding people slow things down? It’s all in the combinatorial explosion.
In a project with n people, the number of potential communication channels between them is calculated as
- A team of 3 people has 3 channels.
- A team of 6 people has 15 channels.
- A team of 10 people has 45 channels.
Every new person added doesn’t just add their hands; they add a massive tax on everyone else’s time. For every hour the new person spends coding, the rest of the team spends three hours in meetings ensuring that the new code doesn’t break the old code. This is why, at Lex Nunc, we value the Law of Small Teams: if you can’t feed a team with two large pizzas, the team is probably too big to be efficient.
Ultimately, Brooks’s law is a plea for architectural integrity over brute force. It suggests that a small, elite team of A-players who actually understand the system will always outpace a massive, disjointed army of resources. It is a reminder that in the world of complex creation, nine women cannot make a baby in one month, and ten extra developers cannot save a project that was poorly planned from the start.