Articles
Having more developers is not always better.
More than 30 years ago Fred Brooks in his classical book “The Mythical Man-Month” showed that increasing developers number in N times will never get as much as N times speed-up in the development process.
But in modern times many IT managers and clients still can’t believe the fact more developers may be counter-productive and take longer than smaller groups.
More developers mean more communication to discuss borders of interactions for different modules and so more meetings that consume time.
Usually one manager is able to coordinate only 5-7 direct subordinates without problems, so increasing number of developers (from 3-7 to 15-20 or even 40) may also increase number of team leaders and project managers: There needs be someone to coordinate developers, track development process, assure code quality and automized tests coverage, build and track schedules, and so on.
Besides developers and managers you’ll also need more QA-engineers because those developers could produce more bugs. If you have team of 3 developers and 1 QA engineer it is ok, but if the team will grow to 10-15 developers your single QA guy would be overloaded and become a bottleneck. So you need to have two QA engineers for testing... maybe even additional QA team leaders to coordinate QA engineers. But development/testing cycle will take longer.
More developers on a project will cause more code merges and more code conflicts. Sometimes resolution of code conflict may take even more time than developing those conflicting code portions itself.
When you are adding new developers to a project they have to deal with work produced before they came - they will need to learn it and learning product domain, existing code will take additional time. To reduce time you may have to delegate existing developers to help new ones but anyway it’ll take time and those helping will spend more time helping instead of producing new functionality or fixing existing bugs.
Development teams usually work in common space: rooms or cubicles. So, if one of developers becomes ill, chances that others may be infected becomes much greater. Imagine, epidemic that’ll cause sickness for 4-5 developers means something like one missed man-month.
What are you are going to do with all the extra staff after the first version of the project is over? It may be very difficult or expensive to find employees who will agree to work on a single project and become fired after it is finished.
As you can see, having more developers may not always be better. It is our experience that small (1-2 developer man-months) to medium (3-15 developer man-months) projects should have as few developers as possible. It is a common situation that a 6 developer man-months project, with a team of 3-4 developers may be done quicker than a project with a team of 8-9.