Brooks Law: Adding manpower to a late software project makes it later.
Last updated: October 22, 2022 Read in fullscreen view



- 27 Oct 2020
8 principles of Agile Testing
- 08 Dec 2021
What Are The 4 Types of Maintenance Strategies?
- 13 May 2022
IT Training and Development: The most effective options for upskilling IT staff
- 02 Dec 2022
3 Levels of Quality in KANO Analysis Model
- 09 Oct 2022
Key Advantages and Disadvantages of Agile Methodology
Brooks' law is an observation about software project management according to which adding manpower to software project that is behind schedule delays it even longer. It was coined by Fred Brooks in his 1975 book The Mythical Man-Month.
Adding manpower to a late software project makes it later. Fred Brooks
The bearing of a child takes nine months, no matter how many women are assigned. Fred Brooks
Adding more resources (usually developers) to a project would seem sensible. If one team have a velocity of 25 story points Sprint (Story points gets internally translated to days by 91 percent of the population). So if there are 4 teams a velocity of 100 story points per sprint.
The reality is teams and individuals don’t start delivering 100 percent instantly because there are other factors to consider.
These other factors have been explained by Brooks Law
Brooks Law
Brooks points to the main factors that explain why it works this way:
- It takes some time for the people added to a project to become productive. Brooks calls this the “ramp up” time. Software projects are complex engineering endeavors, and new workers on the project must first become educated about the work that has preceded them; this education requires diverting resources already working on the project, temporarily diminishing their productivity while the new workers are not yet contributing meaningfully. Each new worker also needs to integrate with a team composed of several engineers who must educate the new worker in their area of expertise in the code base, day by day. In addition to reducing the contribution of experienced workers (because of the need to train), new workers may even make negative contributions, for example, if they introduce bugs that move the project further from completion.
- Communication overheads increase as the number of people increases. Due to combinatorial explosion, the number of different communication channels increases rapidly with the number of people.[3]Everyone working on the same task needs to keep in sync, so as more people are added they spend more time trying to find out what everyone else is doing.
- Limited divisibility of tasks. Adding more people to a highly divisible task such as reaping a field by hand decreases the overall task duration (up to the point where additional workers get in each other’s way). Some tasks are less divisible; Brooks points out that while it takes one woman nine months to make one baby, “nine women can’t make a baby in one month”.
The problems associated with adding new teams is ramping up, individuals need to learn/understand
Increasing people on a project increases complexity of working, collaborating and communicating.
Each new developer has to be introduced to the code base and development process which takes not only the new person's time but also requires assistance from [a] senior developer[s] (guiding them through the build process, explain the testing process, help them with pitfalls in the code base, much more detailed code reviews, etc).
Therefore, the more new developers you add to the project the more time has to be spent to bring them to a point where they can actually contribute to the project.