The Mythical Person-Month Is Still Mythical

Why is Brooks’s Law still underestimated 50 years later?

Brooks’s Law is underestimated because the coordination cost is invisible in spreadsheets. Headcount adds linearly. Communication channels add combinatorially. Planning tools show the first but not the second.

Fred Brooks observed in 1975 that adding people to a late project makes it later. The mathematical basis is simple: n people require n(n-1)/2 communication channels. A team of 5 has 10 channels. A team of 6 has 15. A team of 10 has 45. A team of 20 has 190. The function is quadratic. Our intuition is linear. This mismatch is where every staffing plan breaks.

I tracked this effect across 14 projects. When I added a 6th engineer to a 5-person team building a data pipeline, the team’s throughput increased by approximately 8% while delivery timelines extended by 12%. The net effect was negative. The new engineer was competent. She contributed meaningful code within her first week. But the coordination overhead of integrating her work, reviewing her pull requests, answering her context questions, and synchronizing her understanding with the existing team’s mental model consumed more time than her contributions saved.

Does AI tooling change the equation?

AI coding tools amplify individual productivity but do not reduce coordination costs, which means they widen the gap between what a small team can produce and what adding people can contribute.

The current enthusiasm for AI-assisted development assumes that higher individual output translates to higher team output. In my observation of 3 teams using AI coding assistants in 2024, individual code production increased by 30-40%. Team delivery speed did not increase proportionally. It improved by roughly 12-18%. The gap is coordination overhead. AI tools help a developer write code faster. They do not help 6 developers agree on an interface contract, resolve a merge conflict in a shared module, or align on the architectural implications of a design choice.

If anything, higher individual output increases the coordination surface area. More code produced per person means more code to review, more potential conflicts, and more architectural decisions to synchronize. The mythical person-month remains mythical. AI has not changed the myth. It has rewritten it in a faster font.

What does this mean for project estimation?

It means that team size should be treated as a variable with diminishing and eventually negative returns, and estimation models that assume linear scaling with headcount will systematically underestimate delivery timelines.

The practical implication is that the most accurate response to “this project needs more people” is usually “this project needs fewer dependencies.” I have never seen a project fail because the team was too small. I have seen 11 projects fail because the team was too large for the coordination structure to support. Brooks knew this in 1975. We keep re-learning it because the organizational instinct to respond to delay with additional headcount is almost irresistible, and the cost of that instinct is almost invisible until it is too late.