If building a particular software system is scheduled to take 5 engineers, 6 months, then simple math says that 10 engineers can build the same system in 3 months. (That’s twice the number of engineers and half the time.)
Okay, okay. I know. Some additional communication overhead will be introduced by adding people to the team. Fine. I’m in a generous mood. I’ll give you 4 months. Now get to work.
Not so fast.
Simple math doesn’t always work, particularly when you apply it to complex situations. Also, keep in mind that project estimates are prone to variability and change. A 6-month estimate could represent from 3 to 12 months of work.
Let’s examine some of the factors that affect the productivity of a group of software engineers.
- Communication skills
- Software engineering experience level
- Experience with the toolset
- Work environment
- Ability to learn
- Structure of the system
- Availability of business stakeholders and end users
- Availability of support personnel to document, deploy, etc.
- Availability of target systems to develop, test, etc.
You get the idea. Adding software developers is just the tip of the iceberg. Are all the other pieces in place to make adding developers worthwhile? If so, what’s being done to help this larger team form, storm, norm and perform?
The bigger they are, the harder they fail.
Adding people to an established team at the outset of a project is a questionable idea. As time goes on, the issues listed above only loom larger making adding people well into the project a bad idea. Adding them nearer the end of the project in a mad rush to make up lost time is foolish.
I won’t say that you should never add people to a software development project but if you do, review the list above and take appropriate actions to support the team. Finally, be realistic. Adding a person may only provide half the benefit that the simple math suggests. Adding more than one could even have a negative impact.