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 ThornleyOct 27 '10 at 15:12

12 Answers
12

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.

So if you optimise 'Introduction' then the impact will be lessened?
–
HenryOct 26 '10 at 22:58

6

@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.
–
BaelnornOct 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.)
–
rwongOct 27 '10 at 5:11

5

@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.
–
TMNOct 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 ThornleyOct 27 '10 at 15:11

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.

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.

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.

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).
–
n1ckpOct 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).
–
MurphOct 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.
–
n1ckpOct 27 '10 at 13:41

Ok, the example could be better but the generalisation is still valid?
–
MurphOct 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 TablesOct 27 '10 at 20:14

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.

+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 TablesJun 9 '11 at 23:09

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
–
n1ckpOct 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.
–
rerunOct 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 ThornleyOct 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.
–
n1ckpOct 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?
–
n1ckpOct 27 '10 at 23:27

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.

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.

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.