Essential Project Practices: Throwing more programmers at a project

Fredrick Brooks Jr. made an interesting and in time very well known statement when he coined Brooks's Law in 1975:

"adding manpower to a late software project makes it later"

He himself said it was an "outrageous oversimplification", but it is an observation that has had value in all these years.

I think its primary value lie in the simplicity of the statement. It's a law that can be used to easily argue against common sense: that doubling the amount of developers should double the productivity. And even more, it's a statement which can easily catch the interest to find out why it was stated. One thing is that adding developers to a project won't double the productivity, quite another is to say that it won't increase productivity at all, and it sounds really absurd to say that I will make it later.

The Law is based on a few main points:

• New programmers will have to learn about the project.
• Communication overhead will increase
  

So what can you do to avoid fulfilling Brooks's Law? It's not like its gravity we're talking about here.
There's many factors involved:

• How skilled are the new developers?
• How well do they know the domain?
• How many are they?
• At what time do they come into the project. Early or late?
• How well do they fit into the culture?
• Are they team players that can accept the current process, or will they fight it?
• How well can the work be segregated?
• What practices are in place to ensure the quality of the work produced? Automated testing, Continuous Integration, close customer collaboration, code reviews and lot's more can help to ensure that things don't get out of hand.
• ...

Pretty obvious, but I doesn't hurt to have a law for it.