Home > Uncategorized > How to avoid being a victim of Brooks’ law

How to avoid being a victim of Brooks’ law

The oft cited book The Mythical Man Month contains a statement that has become known as Brooks’ Law: “Adding manpower to a late software project makes it later”.

When people join a project they need to learn project specific information, this is information that can only be obtained from people already working on the project. Training up new staff (e.g., developers, documentation writers) reduces the amount of effort being directly invested in building the system; it is an investment in people whose benefit is the post-training productivity of those people adding their effort to the project.

Let’s assume that a newbie diverts from the project they are joining an amount of effort units of time, E_T, in training without contributing anything, and that this training/investment lasts for D_t units of time after which the trained person contributes an average of E_n of effort per unit of time until the project deadline. This investment in a newbie will cause the project to be delayed unless the following inequality holds:

(E_a D_t - E_T) + (E_a+E_n)(D_r-D_t) > E_a D_r” title=”(E_a D_t – E_T) + (E_a+E_n)(D_r-D_t) > E_a D_r”/> <img src=

where E_a is the average daily project effort available before a newbie joins and D_r is the number of units of time between the start of training and the delivery date/time.

This simplifies to:

D_r-D_t > {E_T}/{E_n}” title=”D_r-D_t > {E_T}/{E_n}”/> <img src=

an equation that makes the obvious point that as the deadline approaches the amount of time and effort spent training newbies needs to decrease if a worthwhile payback is to be achieved in the available time.

The quantity D_r-D_t is the amount of time remaining after the newbie finishes training (in practice this is rarely a well defined point in time, but let’s keep things simple) and is the only easily obtained information in the equation.

The effort contribution of the newbie, E_n, could be approximated using information on the effort contribution of other people doing a similar job on the project. At least it could be if data was available on what their effort contribution was, and we overlooked the possible 5:1 difference in performance found between software developers. In practice a newbie’s effort contribution ramps up from zero, perhaps even starting during the training period, to a relatively constant long term daily average. How long does it take for E_n to reach the long term average? I have no idea.

How much effort, E_T, goes into training a newbie? A very important factor will obviously be their existing level of expertise with the application domain, tools being used, coding skills, etc (pretty much everything was new, back in the day, for the project analysed by Brooks, so E_T was probably very high). There is also the somewhat nebulous but very important ability, or lack of, to pick things up quickly.

Could data on E_T be obtained by recording every encounter the newbie has with existing project members? This would certainly enable information on first order time interactions to be obtained, but it would not tell us anything about the knock on effects caused by the work of an existing project member being delayed because they were investing in the newbie.

If many people are being added to a project at the same time it is easy to imagine it grinding to a halt because of all the minor congestion that occurs within the network of dependencies that project progress is waiting on.

I have not been able to locate any applicable data relating to training on software development projects, but then this area is at the edge of what I know about. Pointers to data most welcome.

  1. Derek R
    July 10th, 2014 at 14:11 | #1

    I wonder if it’s different “these days.” If a big project is organized from the start as a bunch of modules that communicate, and the communication protocol is documented, then it’s more straightforward to hire new people and get them working on separate modules.

  2. July 10th, 2014 at 15:18 | #2

    @Derek R
    Developers have always tried to structure code as a collection of communicating modules, its the only reliable way of building big systems. Projects sometimes start with lots of useful looking documentation, which of course quickly become out of date as writing code uncovers reality and the documentation is not updated.

    The call on training time is not existing code as such, but the higher level assumptions and design targets embedded in the code. Newbies need to learn why things are the way they are and what the short/medium/long term goals are; knowledge that will be scattered about the team or need creating in a way that plugs into what others are doing.

  3. September 12th, 2016 at 17:16 | #3

    Harrison and Copliens book “Organizational Patterns of Agile Software Development” describes project management methods, among others.

    For the case of getting (whether needed or not) a lot of new members in a project, they suggest the pattern “Child Care”, which is essentially the idea of assigning all the questions from a whole bunch of newbies to ONE single previous member, to shield all the others from distraction. If that one previous member has broad-enough knowledge of the whole project, this can be an effective method for escaping Brooks’ law.

    The other half of the trick is assigning the newbies tasks that are almost simple enough that they can do them, so they can learn a lot by themselves, without needing massive amounts of help. Susan Sim describes such behavior in her case study on actual ramp-up in one software organization.

  4. September 12th, 2016 at 18:58 | #4

    @Lutz Prechelt
    Thanks for the link to the paper (the approach looks promising, a shame they did not follow through with something more substantial). Developer fluency: achieving true mastery in software projects is a very interesting paper, and more recently: Ramp-up Journey of New Hires: Tug of War of Aids and Impediments.

  1. No trackbacks yet.

A question to answer *