32

It's a fairly common adage that adding more programmers to a late project will make matters worse. Why is this?

Improve this question
5
  • 15
    The term for this is Brooks's Law (en.wikipedia.org/wiki/Brooks's_law).
    – Macneil
    Oct 26, 2010 at 22:55
  • 8
    Advice: read Brooks' "The Mythical Man-Month". This will show where that adage comes from, it's a very readable book, and everybody in the field should read it anyway.
    – David Thornley
    Oct 27, 2010 at 15:12
  • That Wikipedia page is very well written.
    – Henry
    Oct 30, 2010 at 23:37
  • For evidence of how productivity decreases with team size (beyond 7 team members you get into diminishing returns), see qsm.com/process_improvement_01.html
    – Joeri Sebrechts
    Jun 27, 2013 at 13:21
  • Adding more new people to the project. People who have no previous knowledge of the project, so they have to be taught.
    – Thorbjørn Ravn Andersen
    Apr 23, 2022 at 9:25

13 Answers 13

Reset to default
37

Introduction overhead

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.

Improve this answer
9
  • So if you optimise 'Introduction' then the impact will be lessened?
    – Henry
    Oct 26, 2010 at 22:58
  • 9
    @Henry: the problem is that you usually can't optimize that aspect to a degree where it's not the bottleneck. A new programmer at first knows exactly 0 about your project, your code and your processes. It's the same overhead that's always required when adding a new team member. But when a project is already running late the team often doesn't have the time to do a proper introduction, and if it does that time is missing from the actual development. Therefore it's usually a lose-lose situation for the team and the new person takes much longer until he can contribute meaningfully to the project.
    – Baelnorn
    Oct 26, 2010 at 23:07
  • Regarding the cost of doing an introduction, can't it be video-taped once and then broadcast to many, so that it can train a large number of new programmers at once? (Examples: developer meetings or conferences.)
    – rwong
    Oct 27, 2010 at 5:11
  • 8
    @rwong: It's not a bad idea, but this usually isn't practical. You can't just present the information, you have to make sure the new guys understand it. Plus, if they're really new (recent grads), there's usually too much information to present to them all at once. We've found that a wiki works well, as all the information is in one spot, and people can post questions if there are bits they don't understand.
    – TMN
    Oct 27, 2010 at 12:05
  • One possibility is to assign a very competent new person, and have them do specific tasks without bothering the others. They will flounder badly and work slowly, and some managers and/or teams can't stand to see this. However, the new developer can be a net plus when managed that way.
    – David Thornley
    Oct 27, 2010 at 15:11
33

In addition to the other answers: Another factor to consider is communication.

The worst case for the amount of communication channels on a team (which isn't uncommon), is a complete graph. As you can imagine, adding in just 1 developer can increase the communication channels a lot. With more streamlined methods of communication, the impact is less... but it still adds up.

Improve this answer
4
  • I was writing just the same at about the same time! but I didn't new it had a name (a complet graph) and your explanation is better, so there goes my vote.
    – Miguel Veloso
    Oct 26, 2010 at 22:45
  • +1. Agreed, this is the biggest problem when adding more team members.
    – Martin Wickman
    Oct 27, 2010 at 7:47
  • +1 for the more long term problem with adding people to a project.
    – indyK1ng
    Oct 27, 2010 at 13:48
  • 1
    To my understanding this is why stand-up meetings have been introduced. Everyone hears everyone elses status in a very short timeframe, saving a lot of communication.
    – Thorbjørn Ravn Andersen
    Apr 23, 2022 at 9:26
26

The problem cited in the book the originally promulgated this law, The Mythical Man-Month, is communication. He starts off by saying:

Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them. This is true of reaping wheat or picking cotton; it is not even approximately true of systems programming.

He does mention training as part of the problem:

The added burden of communication is made up of two parts: training and intercommunication. Each worker must be trained in the technology, the goals of the effort, the overall strategy, and the plan of work. This training cannot be partitioned, so this part of the work varies linearly with the number of workers.

...but notes that intercommunication is by far the larger factor:

Since software construction is inherently a systems effort -- an exercise in complex interrelationships--communication effort is great, and it quickly dominates the decrease in individual task time brought about by partitioning. Adding more men lengthens, not shortens, the schedule.

It's also worth noting that Fred Brooks (the author) does have the background to know what he's talking about. Most of the book is based on his experience managing IBM's OS/360 project. Despite decades of adherents preaching all manner of "improved" management methods, and some even coming up with cool names (eXtreme, Agile, Scrum, etc.) when you get down to it, little of essence1 seems to have changed since.

1For the definition of "essence", see the same author's "No Silver Bullet: Essence and Accident in Software Engineering", included in the 20th Anniversary Edition of The Mythical Man-Month.

Improve this answer
12

It's not merely adage; it's verifiable. Check out Brooks' The Mythical Man-Month.

Improve this answer
5
  • 1
    It is an adage. It may or not be verifiable, but that does not stop it being an adage.
    – Peter Boughton
    Oct 26, 2010 at 22:42
  • 3
    I don't have this book (obviously). Is this backed up by hard numbers or is it anecdotal?
    – Henry
    Oct 26, 2010 at 22:59
  • 2
    @Henry: It's been a while since I read it but IIRC, both are present in sufficient quantity to make the point conclusively.
    – Steven Evers
    Oct 27, 2010 at 0:07
  • @Peter: Edited my answer.
    – John
    Oct 27, 2010 at 20:10
  • @PeterBoughton It is an adage. Also, it's not merely an adage.
    – SantiBailors
    Mar 9, 2018 at 12:53
6

Here are some thoughts on this issue ...

  • Need to use current resources to bring the new resources up to speed on what's going on with the project.
  • New resource might not be familiar with the code base, thus required more time to get acclimated to the code.

now, adding new resources for testing might not be a bad idea ... it might speed up the testing process (if your test cases are well written), and yes using testing tools will help too.

Improve this answer
1
  • 1
    +1 for adding resources to testing, not development.
    – Baelnorn
    Oct 26, 2010 at 22:29
6

Fred Brooks wrote an entire book "The Mythical Man-Month" answering this question.

Here's the quick-n-dirty version:

  1. There is a limit to how much you can break a project out into distinct pieces to assign to more programmers.

  2. Splitting a project out to more people increases the amount of communication required to coordinate all the parts of the application. More communication = More Work.

  3. For every person you add to the project you add more than one communication channel that must be navigated to the team. This number grows geometrically and increases the amount of communication that must happen. More communication = More work.

  4. There is a "J-Curve" when you add each team member. That is, the existing productive resources have to spend time getting the new people up to speed that they otherwise could have spent working on the project. Ultimately you may increase capacity, but it temporarily slows down the project. The later in the project the more that must be learned, thus the more pronounced the effect. Also, there is less time remaining in the project to reap the benefits of the newly trained resources.

Improve this answer
4

Because programming is not basic production line work. Getting up to speed on a software project takes time. New people need to ask lots of questions which leads to negative productivity (ie New person learning, old person teaching them -> no actual work getting done).

To simplify it, imagine a relatively simple one-man project which is scheduled to go for 1 week: on Thursday, you realise that it won't get done on time, that it would take the one programmer more like 6-7 days instead of 5. If you add another programmer at that point, they'll need to workn with programmer1 for at least a few hour or a day or so, ask lots of questions to get up to speed, etc. You probably won't get any net positive productivity for the rest of the week. The new programmer is likely to introduce some extra bugs too (since they won't know the existing code as well as programmer1), so that'll blow out the implementation and testing cycle by another day or two more. The project will easily last a full two working weeks instead of the original one! - And most likely longer than if the first programmer was simply given a couple of extra days to finish it themselves.

Improve this answer
27
  • Well, your example is a little contrived by the unrealistic short deadline left to the project. Change it to one month and you will see that it is not necessary true. Personally I think the quote was abused. It is true when considering run-of-the-mill, average/poor programmer. If you have good programmer, and the deadline is not something unrealistic like 1 day or 1 week, then the quote is wrong: it can be done (help the project).
    – n1ckp
    Oct 27, 2010 at 4:30
  • @n1ck Its a generalisation - like "too many cooks" - the key point is that simply throwing manpower at the project won't necessarily cause it to be resolved any faster. 1 person to 2? Probably will. 2 to 4? Too many variables - it depends on the size and structure of the project. 4 -> 8? Definitely getting marginal (at the very least in terms of return on cost).
    – Murph
    Oct 27, 2010 at 9:04
  • @Murph: you seems to be thinking mostly the same things as me but you forgot one very important variable in your equation: skill level of the added manpower. It was in my last comment so I find it strange that you missed it. Blindly adding manpower is of course not the solution. Adding very specialized manpower (you don't need many) can of course help and it is what was missing in the mythical man-month quote. That was my point. Otherwise I aldready know about what the quote mean.
    – n1ckp
    Oct 27, 2010 at 13:41
  • Ok, the example could be better but the generalisation is still valid?
    – Murph
    Oct 27, 2010 at 14:29
  • 1
    I've been through this enough times to know that it's one of those things that MIGHT work in very specialised cases, but 99% of the time it won't. No matter how good it looks in theory at the time. That said, yeah, it's not a black and white absolute. It's more like say, how open relationships don't work. The theory is nice, and tempting ;)....but the nature of the beast is such that in most cases it ends up failing. Sort of a "the exceptions prove the rule" thing.
    – Bobby Tables
    Oct 27, 2010 at 20:14
4

Another factor that I haven't seen mentioned is that some tasks need to be done in a specific order. You can't do task 4 until task 3 is done because it is dependant on 3. It doesn't do any good to hire someone to do task 4 at the same time someone is doing task 3. Often at the end of a project, those tasks that need other things completed first are the remaining tasks.

They are also often some of the most complex tasks that need doing, the very ones which require the best understanding of the whole design to avoid breaking what has already been completed. They also usually require the most extensive business domain knowledge. I might after working on the project for months be able to do the task in a week or less. Someone new would spend more than a week getting up to speed (and pulling me away from my tasks for a good protion of that time to answer questions) and would likely even if extremely skilled take longer to to do the task. Not be cause he or she isn't competent but because of unfamiliarity with the actual structure of the project or the database backend.

Improve this answer
1
  • +1. This was a major issue at my last job. The management was in mega "man month adding" craze for a major project without thinking things through. At one point, our team got drilled for being slow - because our stuff needed to integrate with that major project. But then, the new hires on the major project couldn't get up to speed fast enough, so WE got too far ahead (on stuff that needed their backends completed). At one point we were developing front ends for half-baked backends and test harnesses. Not a good flow.
    – Bobby Tables
    Jun 9, 2011 at 23:09
2

The adage that is always worked for me is you can't get nine women to make a baby in one month.

Improve this answer
9
  • If you think a software project is like a baby, you don't live in the real world. There is some truth in the quote but this is the perfect example of taking things out of context: -1
    – n1ckp
    Oct 27, 2010 at 4:32
  • 1
    Its obviously not. But they people you have sell time lines too don't understand software development. Analogies are exactly for that purpose relating an unknown concept to a know entity.
    – rerun
    Oct 27, 2010 at 12:14
  • 2
    Another analogy Brooks makes is to food in a restaurant. A well-run kitchen can make a lot of meals in parallel, but there's limits as to how fast it can make a single meal without undercooking or burning it.
    – David Thornley
    Oct 27, 2010 at 15:08
  • @rerun: the problem with your analogy is that there is no worker analogy for a pregnant women. The women in your case could be more easily compared to the company, not the workers. That's why it fails so much in my opinion. The closest I can think of would be the food but that would be more like line of codes, so no, not workers.
    – n1ckp
    Oct 27, 2010 at 23:25
  • 1
    @n1ck: My impression is that you disagree because you don't understand it, to be honest. Brooks wasn't talking about replacing useless people with competent people, because he was in a situation where everybody still employed was considered competent.
    – David Thornley
    Oct 28, 2010 at 14:06
2

I'd also suggest "Peopleware" by DeMarco and Lister.

And "The Deadline" by DeMarco presents this, and a number of other software project management diseases and fallacies in a lighthearted and very readable fashion.

It also delves into the dynamics of people doing project / team work, and goes into some detail about just HOW things like communication and introduction deplete the available working time of a team.

These books are quite cheap, I'd suggest you get them (Amazon or The Book Depository have them) and have a read. The short answers here can't really do justice to the question asked.

Improve this answer
0
2

Because no one takes the time to have a well thought out, planned, tested process for: hiring, training, developing and supervising programmers let alone brining them up to speed on a particular project.

If you are managing a team of developers, you should have several contacts right now of people you would like to hire if you have an openning. Join developer groups.

How fast can you get a brand new development machine setup and ready to go?

Have you ever tested your project documentation and specs by showing them to a developer on another project? Did they look at it and determine they could start working on the project if necessary?

How up to date is any project schedule?

Save up for a rainy day because when a project falls behind it is more like a huricane.

Improve this answer
2

Aside from the communication issue (which I think all the other answers are talking about), it’s also very possible for a person added to a project to create bugs, because they don’t know the code very well yet.

Whenever I’m added to a project, I always try very hard not to break things. This means I’m much slower at fixing things at first.

Improve this answer
0

I would like to point out something totally ignored so far by the other answers.

By the time people are added to a late project, typically a lot has gone wrong throughout the organization. Management and the client are not happy. People have been pressured to get on with it. Things are pretty tense.

Now imagine you are on that team. Obviously none of this is your fault. Planning (none of which was yours) has been too optimistic. All the wrong decisions were made without consulting you. You are trying to make the best of it and all of a sudden a bunch of new people are being wheeled in. What message does this convey?

The people upstairs obviously have lost faith in you. They called in the big boys to make up for what you messed up.

Will you still be motivated to make this a success? Or... will you be ever more frustrated and would you rather see the whole thing crash after all?

Take your time :-).

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.