Brooks' law

Adding software engineers to a late software project makes it later.

This law first appeared in a classic book, The Mythical Man-Month. Five decades later, it’s still routinely ignored.

The common response to schedule slippage remains: “Let’s add more developers to catch up”.

The qualifier “late” in the statement of the law is an important one. It suggests that people can be added to projects which are not late. Hence, for example, the success of some open source software projects, which successfully incorporate thousands of developers over the course of their lifetimes.

The central insight is that new developers require onboarding, which in turn requires time of existing developers, which in turn subtracts time from the ongoing project.

Hence, a word of caution for hapless managers who attempt to speed up a project which is running off the rails: adding new resources will only exacerbate the problem.

This mistaken thinking overlooks the fundamental reasons Brook’s Law holds true:

• New team members require onboarding and training, taking time away from existing productive engineers
• Communication channels increase exponentially with team size
• Work division creates opportunity for the team to get misaligned

In practice: As you add engineers onto a project, they need to stay in sync to communicate with others on their work. Each person added has 2 hits to productivity: the initial slow down to onboard the new person and subdivide the work and then the on-going productivity hit to keep them in sync.

Stated more mathematically, with n people, potential communication channels = n(n-1)/2. So while adding 1 new person to 2 team adds in just 2 communication channels, adding one person to a 10-person team creates 10 new communication channels.

There’s a reason that most teams working on a feature will subdivide once it crosses 5 people. You can to drop the lines of communication for coordination from 10 to 4 (1 line + 3 lines).

For more details, read:

• Fred Brooks, The Mythical Man-Month: Essays on Software Engineering, Addison-Wesley, 1975.