After more than 30 years of professional software development, I’ve learned that not only do you need a lot of code to build software but you also need lots of communication. This is what the late Fred Brooks described as a problem in his famous book, The Mythical Man-Month—especially in regard to adding more software developers to an already late software project. The level of intercommunication between people grows to where it impedes progress, and the project becomes increasingly late with each person added.
That’s where Brooks’ Law comes in, which clearly states: “Adding manpower to a late software project makes it later.”
Things are rarely this straightforward. In my opinion, it may have been inaccurate for Brooks to talk about this human-resource paradox as a generalization. It was a problem specific to his project, his team’s architecture, and his team’s choice of languages and tools. He also assumed that all developers are equal and that tasks cannot be easily worked on independently. Even so, over time, studies on many large software projects have proven him correct—enough that Brooks’ Law is, well, Brooks’ Law.
If you buy into the argument that adding people to an already late software project delays it even more, then what can you do to speed things up? It turns out there are some things you can do. A few of the following suggestions are from Brooks himself and a few are my own (for what they’re worth).
To speed up a software project, the Bermuda Plan—part of Brooks’ Law—may sound cryptic but it’s very simple: Send most of your developers on a nice vacation and let your top people do all the work unabated. That’s not very formulaic, but it’s a guideline that makes sense if communication and distraction are the main impediments to progress. It may not be practical, however.
Want a more practical version? Well, you can move developers to critical nondevelopment tasks. This helps to reduce communication delays and assigns developers to finish tasks that help the remaining developers become more productive. For example, developers can be assigned to
You might demoralize developers who are removed from mainline development tasks, and you might also create more costs related to additional release cycles, but these downsides can be managed and controlled.
To minimize intercommunication and interdependencies between software teams, carefully segment your system design to allow teams to work independently—that is, in parallel.
For example, a single team working on a client/server application will require a lot of coordination as they work on the message-by-message communication between the two components of the application.
However, if they first decide to use an independent communication protocol (such as HTTP), the client and server teams can work almost completely independently, as long as each adheres to the communication specification. I would suggest with confidence that you could develop a new web browser today without speaking to a single web server developer.
Pair programming, where two individuals are glued together to work side by side on a single task, can reduce communication needs by half (or more). Instead of each person working on different tasks and needing to communicate across the organization, developers are paired, reducing cross talk. Pair programming helps to further reduce communication problems because knowledge sharing occurs organically, especially when you pair a newer developer with a more experienced one.
The benefits from pair programming often improve productivity for each developer, and for the team as a whole, for the following reasons:
Yes; you read that right. I’m suggesting adding even more people to a late project to help speed it up. That completely violates Brooks’ Law. But it can help in situations where less training and overhead are needed for the added people, for example, if they are technology specialists, proven consultants with exceptional skills and expertise, nondevelopers who have exceptional communication skills, or developers who have experience building similar systems.
In the extreme, the use of competition between internal groups can lead to seemingly miraculous results. You can see examples in Tracy Kidder’s The Soul of a New Machine or in other legendary large-scale development efforts written about in books or online articles.
In my experience, an acquisition can make a difference as well. I’ve witnessed multiple examples where a project’s success was so critical that a decision was made to acquire a company with a similar product or technology to enable progress. This can have multiple side effects that do indeed work:
That suggestion may sound like a snarky comment, but in reality, the original schedule may simply be unattainable, as Brooks’ Law also points out. Scheduling mistakes often account for late projects, which is an issue that extends beyond software development. Just ask any homeowner who’s remodeling, and they’re sure to agree.
Whether or not you can extend the schedule, progress can often be improved by performing tasks more often and working out the bottlenecks. This is in line with the Agile development process, as well as with DevOps, where you release smaller increments more often and get better at doing that. If you can define an incremental release plan where each phase has its own schedule and then divide groups of developers across the phases, you may be able to achieve a higher degree of independence and parallelism.
I would never suggest one language is more productive than another, but Java is a complete platform. Java has a robust virtual machine that abstracts the hardware details and a mature set of tools that help in every facet of development and debugging. In addition, there’s a rich set of commercial and open source software to add value to your projects, powerful IDEs, and a vast community to turn to for help.
Recent language changes aid Java developers’ productivity. These changes include records, type inference, easier switch syntax and other switch enhancements, simplified text blocks, simplified concurrency with virtual threads and platform threads, I/O enhancements, and much more.
Eric J. Bruno is in the advanced research group at Dell focused on Edge and 5G. He has almost 30 years experience in the information technology community as an enterprise architect, developer, and analyst with expertise in large-scale distributed software design, real-time systems, and edge/IoT. Follow him on Twitter at @ericjbruno.
Previous Post