The Benefits of Pair Programming

November 16, 2010

In my last post, Results through Pair Programming, I took a quick look at what pair programming is, and noted that there are two flavors:
  1. Collaboration with driver/navigator roles, splitting responsibility for the tactical coding and strategic aspects.
  2. Collaboration by sharing and dealing with the tactical coding and the strategic issues together.
Purposeful collaboration is the common component in both cases; pair programming is not about someone looking over your shoulder and making comments like, “Oh, you missed a semi-colon!” The compiler can do that job, and quite frankly, that would drive me nuts.

The following are the top five benefits of pair programming from my perspective.

1. Improves design quality: A controlled experiment reported in Strengthening the Case for Pair Programming found that pair programmers produced superior designs. The article states, “The design from the collaborative teams exploited more of the benefits of object-oriented programming. Their classes demonstrated more encapsulation and had more classes with better class-responsibility alignment. The individuals tended to have fewer classes that had many responsibilities. The collaborative designs would, therefore, be easier to implement, enhance and maintain.”

2. Reduces defects: Various studies (as reported in Pair Programming on Wikipedia) report a reduction in defect rates for pair programming, ranging from 15% to 50%, with the variance attributed to programmer experience and task complexity. One way that defects get reduced are through superior design, the other is through the fact the pair programming provides a continuous design and code review. Jeff Atwood discussed the advantages of design and code reviews in a post Code Reviews: Just Do It, citing Steve McConnell’s book Code Complete and other studies. For example:

“In a group of 11 programs developed by the same group of people, the first 5 were developed without reviews. The remaining 6 were developed with reviews. After all the programs were released to production, the first 5 had an average of 4.5 errors per 100 lines of code. The 6 that had been inspected had an average of only 0.82 errors per 100. Reviews cut the errors by over 80 percent.”

This also gets around another real-world difficulty: most programmers do not enjoy code reviews, and more often than not, they won’t be performed unless mandated. And when they are mandated, the process isn’t exactly embraced... (And managers are labeled as evil.)

3. Accelerates problem-solving. If you are appropriately applying pair programming, then you are pairing on those difficult, complex tasks where it is advantageous to have more than one person chart a course. The article, Strengthening the Case for Pair Programming found that pair programmers “…constantly refer to the team's ability to solve ‘impossible’ problems faster.”

4. Broadens the understanding of the code base. How many “beer truck” scenarios do you have? Too often, critical knowledge software is stored in the heads of too few. (And sometimes only one.) Pair programming is a mechanism to spread the knowledge around, thereby reducing your staffing risk.

5. Increases job satisfaction. There are a couple of ways that this happens. First, people find the experience more enjoyable than working alone. This is definitely true if pair programming is used for challenging problems, not for simple coding tasks. The other is way that satisfaction is increased is through – pardon the cliché – “a job well done.” Better design, less defects, accelerated problem-solving. What's not to like?

For another, more in-depth look at pair programming, I’ll point you to an article, Pair Programming: What’s in it for me? By Andrew Begel and Nachiappan Nagappan.


Justin Freitag said...

The benefits of pairing aren't just for programming either!

November 16, 2010 at 4:51 PM
Dave Moran said...

@Justin: LOL! Thanks for reading.

November 16, 2010 at 5:20 PM

Pair program is that Two programmers work together at one workstation. One, the driver, writes code while the other, the observer or navigator.This is a good post. I am a writer. As a writer I think this give more new ideas and information for readers. Scholarship essay writing service will helps to understand about this topic.

June 3, 2016 at 3:20 AM

Post a Comment