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 1101
- 08 Dec 2021
What Are The 4 Types of Maintenance Strategies? 878
- 13 May 2022
IT Training and Development: The most effective options for upskilling IT staff 862
- 02 Dec 2022
3 Levels of Quality in KANO Analysis Model 849
- 21 May 2022
"Fail Fast, Fail Often, Fail Forward" is the answer to Agile practices of software success 804
- 03 Nov 2022
Questions and answers about Kano Model 681
- 09 Oct 2022
Key Advantages and Disadvantages of Agile Methodology 656
- 13 Oct 2021
What is Bug Convergence? Why is it important for User Acceptance Testing (UAT)? 592
- 14 Oct 2021
Stream Story - Low land stream or fast moving stream? 530
- 28 Oct 2023
The GOLDEN Rules of Software Engineering 465
- 12 Oct 2020
The Agile Manifesto - Principle #8 422
- 04 Mar 2023
[Medium] Box-Ticking: The Management Strategy That’s Killing your Productivity 416
- 16 Jul 2022
What are disadvantages of Agile Methodology? How to mitigate the disadvantages ? 341
- 02 Nov 2022
Frequently Asked Questions about Agile and Scrum 324
- 10 Apr 2022
Agile self-organizing teams: What are they? How do they work? 323
- 01 Oct 2020
Handling tight project deadlines as a business analyst 304
- 20 Nov 2022
Agile working method in software and football 283
- 01 Dec 2022
Difference between Set-based development and Point-based development 278
- 05 May 2021
TIGO Magic Scale - PoC tool for you to apply dichotomous thinking before submitting RFP 270
- 07 Oct 2020
How To Manage Expectations at Work (and Why It's Important) 237
- 01 Mar 2022
Why Does Scrum Fail in Large Companies? 230
- 03 Jul 2022
Manifesto for Agile Software Development 226
- 11 Oct 2021
10 Myths About Low-End Project Management Software 225
- 28 Nov 2023
Scrum Team Failure — Scrum Anti-Patterns Taxonomy (3) 218
- 01 Jun 2022
How Your Agile Development Team is Just Like a Football Team? 193
- 21 Oct 2022
Virtual meeting - How does TIGO save cost, reduce complexity and improve quality by remote communication? 135
- 10 Oct 2022
Should Your Business Go Agile? (Infographic) 98
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.