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).
Use the Bermuda Plan
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
◉ Improve deployment processes (DevOps).
◉ Improve system architecture to support parallel programming teams.
◉ Implement or enhance automated testing.
◉ Build out lab resources to reduce hardware bottlenecks.
◉ Build or identify tools to help coding and debugging.
◉ Improve documentation to help get other developers up to speed.
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.
Design the system with proper segmentation
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.
Leverage pair programming
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:
◉ Individual programmers can focus on their strengths as part of a pair.
◉ The organization is often more resilient against employee turnover.
◉ There is less schedule impact when people need time off.
◉ Having multiple people working on the same problem and code tends to result in fewer defects to fix later. This is also known as Linus’ Law, named after Linus Torvalds of Linux fame.
◉ With additional people participating in the same conversations, misunderstandings are reduced and communication is often reduced because there is less rehashing.
◉ Best practices and time-saving techniques are easily shared and spread throughout the team.
◉ With rubber ducking, as described in The Pragmatic Programmer by Andrew Hunt and David Thomas, debugging is improved, mainly due to human nature: One person explaining something to another helps to uncover issues very quickly.
◉ When people work together, they tend to stay more focused, reinforce each other’s confidence and strengths, and generally desire to be more productive so as to not let the other person down.
Add more people
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:
◉ An acquisition can serve as a catalyst for renewed hope and energy that reinvigorates the original team.
◉ There’s an infusion of fresh talent that was not hired by the original team.
◉ Unintended but healthy competition can result.
◉ A new camaraderie between developers can improve teamwork.
◉ New managers who are unafraid to ask questions and suggest changes are infused into the project.
◉ New design patterns and ways of thinking can unlock unrealized time savings.
◉ Additional thought leadership, instead of added developers, can help increase a project’s velocity.
Extend the schedule, if you can
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.
Use Java!
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.
Source: oracle.com
Posts
0 comments:
Post a Comment