WhyPairProgrammingIsBeneficial

UserPreferences

In here we talk about why pair programming is beneficial. We answer the question "why doesn't pair programming take twice as long?"

Most of this was taken from the research and writings of Lauri Williams (http://collaboration.csc.ncsu.edu/laurie/pubs.htm). Our experience confirms all of what is written below.

Pair-Pressure: Less likely to violate coding standards. Less likely to forget to write unit tests. Less likely to do a sloppy or "just get it done" job. More focused on the problem and less likely to be distracted by phone calls, email, etc.

Pair-Think: Based on cognitive theory "Searching Through Larger Spaces of Alternatives". Pair Programmers "explore a larger number of alternatives than a single programmer alone might do. This reduces the chances of selecting a bad plan." [Flor] - Each programmer brings different prior experiences to the task. No programmer has all the experience, knowledge and background that the other programmer has. If you've never dealt with some particular class in some class library, chances are, your pair has. - Whoever is driving must think through the problem and their approach enough to explain it to the pair. This alone helps programmers build better solutions. - Communication is key here. If you can't think out hte problem well enough to explain it to a human, you had better not start trying to code it. Individual programmers tend to jump into writting as they think out the problem. This "Stream Of Conciousness" programming is risk. Pair programming is very effective in stopping this. -- GregHouston - No two programmers will implement a task the same way. Some approaches are better than others. Two heads are truly better than one. The pair will keep bad designs from getting into the system. - Programmers often use the first solution that comes to mind. Each programmer in a pair will suggest the first (bad) solution that comes to mind. But the other programmer in the pair can almost always see it for what it is. So, both programmers are forced to think harder and come up with better solutions. - Similarly, one partner will keep the other from going down a rat-hole. - Distributed memory: When programmers realize the current course of action is wrong, they often reconsider ideas previously rejected. But no one programmer remembers all alternatives considered. Pairs have more memory between them than do individual programmers.

Pair-Relaying: - Pair Programmers can go faster because they don't get stuck. (They have 4 Eye Drive.) Lone programmers do get stuck. And when they do, they spend hours looking for a solution. With pair programming, when one programmer is stuck, the other isn't: he has a different point of view, different insights to the problem, and different prior experiences. The other programmer takes over.

Pair-Reviews: Everyone knows peer-reviews (inspections, walk-throughs) are a cost-effective way to improve quality. But no one likes to do it. Pair-programming achieves the objective, and is actually enjoyable. In fact, pair programming removes more defects than traditional, formal code reviews.

Debugging by Explaining: ...[an] effective technique is to explain your code to someone else. This will often cause you to explain the bug to yourself. Sometimes it takes no more than a few sentences, followed by an embarassed "Never mind; I see what's wrong. Sorry to bother you." This works remarkably well; you can even use non-programmers as listeners. One university computer center kept a teddy bear near the help desk. Students with mysterious bugs were required to explain them to the teddy bear before they could speak to a human counselor. [Kernighan]

Pair-Learning: - Programmers, no matter how experienced, do learn from other programmers, no matter how junior. No two programmers have had the same experiences. New approaches, ideas, idioms spread quickly through the team (via the "pair-vine"). - Investing in new team members and in junior programmers (teaching them what the team knows) is beneficial to the team -- New team members and junior programmers learn more quickly when pair programming. The quicker they learn, the quicker they become more productive memebers of the team. - Pair-Learing was very effective in Events. Half the team was new to Java. But, Pair Programming enabled everyone to be productive as they learned. We Paired experience Java developers with new Java developers without any problem. -- GregHouston

Team-Building: Everyone has biases, prejudices, and preconceived notions. "I don't think I would enjoy pairing with so-and-so. I bet he isn't a very good programmer." This is harmful to the team -- it hinders cooperation, communication and effectiveness. Pair programming forces team members to work together, literally side-by-side. As they work together, these biases and prejudices quickly vanish. The result: a stronger team. In those cases where some team member is indeed a poor programmer, he will either learn from the team, or he will leave the team. This will likely happen naturally. If it doesn't, then it will be clear to everyone on the team, including the manager, that the individual isn't working out. What needs to be done will be obvious.

Reduced Risk: "How many or few people would have to be hit by a truck (or quit) before the project is incapacitated?" If you aren't pair programming, loosing most anyone could be a disaster. If you are, then everyone has experience in all parts of the system -- you aren't so vulnerable. What's more, you'll never have to say "that'll take 3 months because it'll require either Joe or Sue and they are tied up for the next month." When pairing, the feature can be split up among all team members. The feature can be done more quickly than if all you have are Joe and Sue. - Since PairProgramming leads to CollectiveOwnership , we have seen fewer contention or block problems in development. For example, module A depends on B. To make a change in A, you have to change B. With CollectiveOwnership you are free to change B, you are not blocked by the owner of B. -- GregHouston

Other ideas to stick somewhere above: - Junior programmers do indeed help more experienced programmers. Some ways/reasons: they may have picked up something new in school / from a book; they have a different vantage point to the problem by virtue of their current role in the pairing; they help remember variable / method names / parameters; they help remember the big picture; they do the typing while the more experienced programmer thinks about the big picture; they help point out errors, typos; etc etc etc - I frequently get asked "Can people at different experience levels pair?", the answer is most definately YES! We have found both Pro and Newbie developers reported find pairing with different experience levels beneficial. -- GregHouston

Many people's gut reaction is to reject the idea of pair-programming because they assume that there will be a 100% programmer-hour increase by putting two programmers on a job that one can do. After the initial adjustment period the total programmer housrs spent on each assignment trended downward dramatically... Together the pairs only spent about 15% more time on the program than then individuals. Additionally, after the first, program, the difference between the times for individuals and for the pairs was no longer statistically significant. ...[p-values indicate] that there is almost a 40% chance the [15%] difference in time values would be observed by chance. [Williams]

Also, Williams states that PairProgramming alone (she was not using other XP practices) resulted in 15% better quality. Since it takes so long to fix problems, the 15% improvement in quality outweighs the 15% slow down in initially completing the task. -- GregHouston

When you add it all up, pairs really do go faster.

References: Flor, Hutchins, "Analyzing Distributed Cognition in Software Teams: A Case Study of Team Programming During Perfective Software Maintenance," presented at Empirical Studies of Programmers: Fourth Workshop, 1991.

Kernighan, Pike, The Practice of Programming. Reading, Mass, Addison-Wesley, 1999.

Williams, "The Collaborative Software Process", submitted for consideration, The University of Utah, August 2000.

-- AndrewFuqua - 06 Feb 2001