Clients sometimes ask us “Can you add more developers to the project so we finish sooner?”.
To a degree, yes, but adding more developers can also slow progress and increase costs. It’s not as simple as saying “This is a 20 week project, we’ll double the number of developers and finish in 10 weeks instead.” There are quite a few reasons why.
The Mythical Man-Month
In Frederick Brooks’s seminal book “The Mythical Man-Month”, the main takeaway is that adding more developers to a project makes it more likely to be delayed.
Brooks’s Law: “Adding manpower to a late software project makes it later.”
Although many of the solutions that Brooks prescribes in his book are a little dated, the idea that adding more developers to a project (especially late in the process) will slow development down, is still a valuable lesson for any project manager or customer who will be having software designed for them.
Why Less is Sometimes More
Software Development is complex, but humans are even more complex. And it is humans who create software.
Ask any two developers the best way to approach a complex problem and you will get two different answers, maybe even three or four.
If minor details like choice of UNIX editors, or whether to use spaces or tabs can lead to disagreement among developers, think about what happens when two or three or ten developers disagree about the best way to handle a complex problem that might have many legitimate solutions.
The Act of Development Creates Complexity
Even if developers are of the same mindset, and agree upon the architecture, development language, frameworks and even a shared coding style, the act of development itself adds complexity.
Figuring out where something happens in code that you haven’t written, can take hours. Looking through thousands of lines of source code and trying to grasp what is going on is a daunting task.
Twenty-some years ago I bought a book that was the entire source code to the Apache Web Server (with commentary). I foolishly believed that I was going to read it on an 18-hour flight to Australia.
After a few hours of endlessly flipping between pages trying to determine what was going on I gave up. But, for some reason I dragged that 5-pound book backpacking all over Australia.
Modern IDE’s make navigating code much more productive than reading that book, but bringing a developer into an existing project is very much like asking them to read a giant book of software code.
More Developers Means More Communication
In The Mythical Man-Month, Brooks clearly lays out that the more developers there are, the more paths of communication there are.
He gives the example that if there are 50 developers, there are 1225 separate paths of communication. But Brooks lived in the days before email, if you include Slack, Jira, verbal conversations, written documentation and whatnot, there are probably 5000 different paths of communication.
Information and knowledge central to the understanding of how an app is built, and functions, can be lost if there are 50 developers communicating in different places. Not to mention the additional time spent in communication as you add more and more developers to a project.
Working on Small Portions of Code
A proposed solution is to break a project into small parts and give each part to a different developer. And while this is probably the best approach, it too can be fraught with other problems.
First of all, it is very difficult to isolate a section of development. Frequently when that happens, portions of the project that were thought to be distinct, introduce problems when they are co-mingled into the main project.
Secondly, the act of planning, preparing and documenting for these small projects can be as big as the project itself. The developer time spent just “divvying things up” leeches time away from the main project.
I once had a manager who believed he could hire inexpensive freelancers for a medium-sized project. He had his salaried developers define the components for each freelance developer and planned to have them “wire it all together” when the freelancers were done.
After spending weeks writing the technical specs for all the components, the salaried programmers went on to other tasks while they waited for the freelancers to complete theirs.
Six months later when the last freelancer finished their work, the salaried developers began to try to integrate all the components. As you can guess, it did not go well. Most of the components sort of worked (they passed the tests required for the freelancers to get paid), but they did not work together. Adjusting things to make them work together proved almost impossible.
In the end, many of the components needed to be rewritten from scratch. The project eventually ended up costing much more in salaried developer time than it would had the developers just written the components themselves (not to mention the freelancing expenditure).
The Interconnectedness Of All Things
One of the reasons that developing software is difficult is that by its nature, code is very interconnected. One of the goals of modern software development, and something we plan for here at Big Fish, is to limit connectedness or coupling – but that is another article.
Frequently when you break tasks apart, one task relies on another and cannot be completed until the other is finished — this is why Gantt Charts and other project planning tools exist.
Even if you break projects into separate components (ex. iOS App, Android app, Rest Services) there are always dependencies.
If the iOS app depends upon Rest Services, the project cannot be completed until the Rest Services are completed. Even if the iOS developer uses dummy data until the Rest Services exist, there will be some level of integration and adjustment once the real services are in place.
Is There Hope? Should All Projects Be Built by One Developer?
A single developer working on a large project is not scalable. But now you can see why adding more developers to your team may not have the impact you were expecting on the delivery timeline.
Large projects do require teams, and that’s not something that can be avoided.
However, the secret is to plan to have a large team from the beginning and understand that growing the team is expensive (at least from a time perspective).
The other lesson is to be aware of where a large developer team leads to problems, and have best practices in place to counteract the potential problems.
