Did you ever have the feeling that adding people doesn’t help in software development? Did you ever think about the reason? And do you have any idea to make a change?
Traditional software engineering emphasizes on division of work by modules, values cooperation between developers. This looks reasonable at first glance, because it is what we are used to do in the production line of traditional industry. But software development is not a production process, this is why we call it software development rather than software production. The closer analogy for software development is the new production development in traditional industry.
The major challenge of software development is in design
, which is about idea but labor. The quality of design can’t be improved by adding hands. It even hurts sometimes, because more people means diffusion of responsibility and higher communication cost. The communication cost is considered one of the major problem in software development. We usually see that to implement a feature we can change module A or module B, the owners of the modules argue with each other that the change should not be made in their own module. Division of work causes people think from their own local point of view, and protect their own interests, but the whole system hurts. Remember that modules can be loosely-coupled, but people have to work closely to make the whole system work. Traditional software engineering emphasizes on improving communication, but I think the otherwise, the better way is reducing unnecessary communication.
Instead of adding hands, what really makes sense is finding the intelligent brains.
Quality comes from intelligent brains
. As we know, most of the master pieces don’t come from cooperation, and so is the good design and implementation in software. For a highly-cohesive complex system like Android, it really doesn’t need dozens of people and division of work to have it come true, actually only 2 or 3 intelligent people is enough. In which case dozens of people are really needed? It must be many unrelated systems, such as, Bing, Office and MSN in Microsoft. For any highly-cohesive complex system, I didn’t see there’s any reason that 2 or 3 excellent developers are not enough. If 3 people can’t make it, 100 neither. The point is not in hands, it’s in brain. Besides finding the intelligent brains, provided with currently available people configuration, what can we do better?
In my development practice, I value the following practices:
1) Collective Ownership. That means we don’t assign a module to a specific developer, instead every developer can write code for any module. The ownership of code is shared within the team.
Everyone Know All
is the philosophy behind. I really appreciate this philosophy in software development. Some say it’s too hard for every developer to know every module, this saying is not true. Average IQ is enough to handle every module of complex system like Android, I believe it without any doubt. Do you think your system is more complex than Android? The key is your determination.
2) Task/Issue Ownership. Code ownership is shared, but every task or issue should has an owner, and we need to track the status of task or issue regularly. The owner should be able to work on many modules to finish the task or resolve the issue. Task/Issue ownership makes developers focus on what really makes sense to user, think from the system level, avoid arguing between modules.
3) Pair Programming/Peer Review. Pair Programming/Peer Review is totally different from traditional division of work. It’s not division, it’s working together. Pair Programming and Peer Review give inspiration to design, and give feedback to implementation, so they really improve the quality a lot. Even more, people grow much faster in this environment.
To sum up, the idea of having many people and division of work by modules is not a good fit for software development. Remember the 2 golden rules for software development: 1) We need brains but hands. 2) Don’t divide, integrate!