Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 14 down vote favorite
4

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

share|improve this question
10  
The term for this is Brooks's Law (en.wikipedia.org/wiki/Brooks's_law). – Macneil Oct 26 '10 at 22:55
4  
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 '10 at 15:12
That Wikipedia page is very well written. – Henry Oct 30 '10 at 23:37

12 Answers

up vote 23 down vote accepted

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.

share|improve this answer
So if you optimise 'Introduction' then the impact will be lessened? – Henry Oct 26 '10 at 22:58
5  
@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 '10 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 '10 at 5:11
3  
@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 '10 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 '10 at 15:11
up vote 24 down vote

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.

share|improve this answer
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 '10 at 22:45
+1. Agreed, this is the biggest problem when adding more team members. – Martin Wickman Oct 27 '10 at 7:47
+1 for the more long term problem with adding people to a project. – indyK1ng Oct 27 '10 at 13:48
up vote 17 down vote

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.

share|improve this answer
up vote 12 down vote

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

share|improve this answer
It is an adage. It may or not be verifiable, but that does not stop it being an adage. – Peter Boughton Oct 26 '10 at 22:42
+1 for citing THE answer to this question – STW Oct 26 '10 at 22:49
1  
I don't have this book (obviously). Is this backed up by hard numbers or is it anecdotal? – Henry Oct 26 '10 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. – Steve Evers Oct 27 '10 at 0:07
@Peter: Edited my answer. – John Oct 27 '10 at 20:10
up vote 4 down vote

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.

share|improve this answer
+1 for adding resources to testing, not development. – Baelnorn Oct 26 '10 at 22:29
up vote 4 down vote

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.

share|improve this answer
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 '10 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 '10 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 '10 at 13:41
Ok, the example could be better but the generalisation is still valid? – Murph Oct 27 '10 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 '10 at 20:14
show 22 more comments
up vote 2 down vote

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.

share|improve this answer
up vote 2 down vote

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.

share|improve this answer
+1 both good books – Gary Rowe Nov 24 '10 at 16:03
up vote 2 down vote

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.

share|improve this answer
+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 '11 at 23:09
up vote 1 down vote

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

share|improve this answer
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 '10 at 4:32
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 '10 at 12:14
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 '10 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 '10 at 23:25
@David Thornley: this one is better but I think it still fail because you way overestimate the staffing that occur in any project. Management rarely, if ever, would staff a project to the max, more like the minimum amount, don't you think? Also, stop discussing about quantity and think quality. Fire those workers that are useless and replace them with highly skilled workers. Now see why I disagree with the quote? – n1ckp Oct 27 '10 at 23:27
show 3 more comments
up vote 1 down vote

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.

share|improve this answer
up vote 0 down vote

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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