Follow @RoyOsherove on Twitter

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.

Scrum at Microsoft

VB user group meeting this week: Diving into ADO.NET 2.0 and VS 2005 Data features