It's a fairly common adage that adding more programmers to a late project will make matters worse. Why is this?
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.
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.
It's not merely adage; it's verifiable. Check out Brooks' The Mythical Man-Month.
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.
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.
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.
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.
The adage that is always worked for me is you can't get nine women to make a baby in one month.
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.
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.