One of the biggest mistakes software companies can make is to assume that more developers will result in more rapid product releases. It doesn’t. This initially seems illogical, however, the law of diminishing returns applies to most industries. And there’s truth to the old adage about too many cooks…
Software development is an unusual and complicated process. Unlike other forms of manufacturing, there is an infinite variety of outcomes and every part of the process is integrated. Seemingly difficult processes can be quick and simple to implement, whereas easy functions can have hidden complexity.
However, one of the primary reasons why more developers != faster development is that a larger team increases communication complexity. When a component is created or modified, it has an impact on other parts of the project. For example, assume developer A is writing a database connectivity class and decides to make a simple change — such as swapping the order of two parameters.
- In a team of 1, the developer can make the change without communicating with anyone.
- In a team of 2, the developer must inform one other person.
- In a team of 3, there are two others to inform.
Therefore, in a team with N members, a developer must contact (N-1) others about the change. Since any team member could make a change at any time, there must be N * (N-1) lines of communication. However, since developer A communicating with developer B is the same as B talking to A, we can divide that total in two. Our final equation:
C = N (N – 1) / 2
Where N is the number of team members and C is the total lines of communication.
Unfortunately, these lines of communication increase exponentially with every additional member. A team of 5, has 10 lines. A team of 10 has 45 lines. A team of 20 has 190 lines. And a team of 100 has 4,950 lines.
It doesn’t matter how you operate your communication channels. Every developer must decide whether a change affects their code and implement updates accordingly. The complexity of software development then raises other issues:
- has everyone received and understood the change?
- do some team members require further assistance?
- does developer A need to justify the update to other team members?
- has the change been tested across all systems?
- does the change lead to a cascade of changes in other components?
It’s not just code changes. Any project decision must be dispersed throughout the team.
Complex projects take time and throwing resources at an over-running schedule won’t necessarily help. You may need to accept that the schedule wasn’t realistic from day one.
Craig is a freelance UK web consultant who built his first page for IE2.0 in 1995. Since that time he's been advocating standards, accessibility, and best-practice HTML5 techniques. He's created enterprise specifications, websites and online applications for companies and organisations including the UK Parliament, the European Parliament, the Department of Energy & Climate Change, Microsoft, and more. He's written more than 1,000 articles for SitePoint and you can find him @craigbuckler.