Thoughts on Division of Work – Todd Wei

综合编程 2013-09-24

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!


We created the Crystal language, ask us anything! Hi there! I'm Matías García Isaía, and together withBrian Cardiff andMartín Verzilli, we're part of the Crystal Team working a...
Suggest.el: Synthesising Constants Suggest.el v0.4 is now out, and it offers some really interesting new ways of making suggestions. Supplying Constants Suppose the user giv...
Assorted fixes I’ve had a post in the works for a while about my work to make return faster (as well as routines that don’t return), as well as some notable multi-di...
WePhone开发者的悲剧,无关是不是程序员... 前几日,WePhone应用的开发者纵身一跃,结束了自己年轻的生命。于前因后果,此不想再诉,蝉大师APP数据分析平台,无心也无力将整个事件再来一次抽丝拔茧,因为我们不想再加剧任何人的痛苦。但对于这位WePhone开发者来说,他的悲剧,是在对的时间里,通过错误的平台,结识了本该此生陌路的人,并且还组合了...
520. Detect Capital 题目: Given a word, you need to judge whether the usage of capitals in it is right or not. We define the usage of capitals in a word to be right whe...