Interesting technique from Pivotal Labs:
One of the first things you’ll notice about us is that we pair program. This means that two developers sit down together at one computer, and write code together. Perhaps surprisingly, two developers can produce more and better code more quickly by working together this way. Why is that? There are a number of reasons. For one, pair programmers spend more time doing productive work. They are constantly engaged, refining ideas, and they discard bad ideas quickly, saving projects from poor choices that can cost weeks of work down the road. Beyond that, with enough eyes, all problems are shallow. If we look at what a typical developer spends time on, much of the time spent is spent stuck on relatively trivial problems, often ones that same developer would breeze through on a different day. When two developers collaborate, one can press on when the other gets stuck, and the flow is never broken. Progress is made consistently and rapidly. We’ve found it the best way to work, and use it on all of our projects, particularly the ones we pay for ourselves. The quality of the code produced is superior, and the time spent to produce it is shorter.
The Effect of Team Size
Developers are most effective when they collaborate full-time, to bring more perspectives to bear on the problem at hand. To this end, we always deploy programmers in pairs. How many pairs to choose is up to you, the customer, but we wanted to provide you some guidance as to how to look at the decision.
One pair is the smallest team you can choose. Typically this is the right team size at the beginning of a project, when the team is just getting up to speed on the particulars of the application being developed. One pair is enough to do solid work, but as the project moves forward, it is useful to change up who pairs with whom. With one pair, there is only one pairing. With two pairs, there are 6 possible pairings, and the team typically produces about twice as much work. Three pairs offers more pairings, and typically produces just under 3 times as much work as a single pair, but can start to suffer from the inability to parallelize tasks. This often depends on the scope of the particular project, and how well the work can be segmented. With more than 3 pairs, communication overhead starts to become a cost, but when time to market is the key consideration, larger teams, as large as 5 pairs, can make sense, particularly for short stretches when the needs of the project are sufficiently segmented. At 5 pairs, you should expect to add one additional full-time person in a leadership role to coordinate the efforts of the team.