How Do You Explain Pair Programming?

Here's something to put on my slides for the next executive briefing I'll talk at. It's about the benefits of pair programming and it's only a part of a whole list of benefits found when doing Pair Programming. It was mentioned as a comment to a question by Johanna Rothman on her blog, looking for ways to explain Pair Programming to management.
 
"1. Projects with high quality (attention to quality) have lower schedule pressure:
  • Products with the lowest defect counts have the shortest schedules (Jones 1991, Applied Software Measurement).
  • Poor quality is the most common reasons for schedule overruns (Jones 1994, 4000 projects, Assessment and Control of Software Risks).

2. Higher quality comes through culture/values/process, inspection, testing, early feedback, refactoring, and so forth.

3. Regarding inspection and quality and schedule, inspection is a powerful tool:
  • Inspections have been found to produce net schedule savings of 10 to 30 percent (Gilb and Graham 1993, Software Inspection).
  • Each hour spent on inspections avoided an average of 33 hours of maintenance (Russell 1991, IEEE Software).
  • Inspections were up to 20 times more efficient than testing (Russell 1991, IEEE Software).

4. PairProgramming, in part, is a way to do effective, real-time, responsive inspection, which supports higher quality, which supports reduced schedule pressure.

 
Personally, I make all the people who take my classes do the exercises in Pairs. First of all, they learn much faster than they would solo. Second, it makes it easy for me to spend more time with each pair as they learn together, which means more quality time during exercises (which make up about 70% of course time when I teach Test Driven Development). Pairs work better. When they can work together, that is.
Published Monday, April 04, 2005 2:08 AM by RoyOsherove
Filed under:

Comments

Sunday, April 03, 2005 8:57 PM by Raymond Lewallen

# re: How Do You Explain Pair Programming?

I'm going to be doing a full day xp workshop in about 2 months. This will be the first xp workshop I've done, and pair programming is one of the things I'm still concerned about being able to explain effectively. There is still a very common mentality of code ownership (developer owned and not team owned) that is hard for many developers to overcome. I think getting people to understand the need for pair programming and collective ownership of code is probably getting simpler these days because I think of lot of developers are beginning to understand the positive impacts.
Monday, April 11, 2005 11:06 PM by TrackBack

# Interesting finds last week ...

Interesting finds last week ...