关于分工的思考 (Thoughts on Division of Labor)
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, which is considered one of the major problem in software development. We usually see that to implement a feature, modification can be made in module A or module B, the owners of the modules argue with each other to reject the modification in their own module. Division of work causes people think from their own local point of view, and protect their own interests, however 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 cooperation, but I think the otherwise, the better way is reducing unnecessary cooperation, in other words, reducing unnecessary division of work.
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 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 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 equally 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) Feature/Issue Ownership. Code ownership is shared, but every feature or issue should has an owner, and we need to track the status regularly. The owner should be able to work on many modules to finish the task or resolve the issue. Compared with module ownership, feature/issue ownership reduces unnecessary communication cost, avoids many argues between developers of different modules. It also makes developers focus on features that really make sense to user, and think from the system level.
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!
