PairProgramming
What Are The Benefits Of Pair Programming?
Wikipedia and many papers take on faith that Pair Programming
- imposes an extra 15% in man hours
- reduces defects by 15%
Assuming that defect resolution takes at least a comparable time to initial development, this would make Pair Programming at least a wash purely on economics grounds.
However these 15% figures stem from a single study in the University of Utah in 1999 using advanced undergraduates: they should not be taken as a clinching cast-iron argument.
A better way to weigh up pros and cons of PP would be by looking at the full range of benefits it can bring:
- Talking about the task while performing it gets benefit from engaging brain's language processing facilities
- Two pairs of eyes alleviates change blindness (rotating pairs gets the most out of this)
- Helps keep good practice up / discipline
- Sharing information / improved calibration of expertise levels
What Studies Show
A few common threads do emerge from the studies that have been carried out around PP:
- It is most effective when the task pushes the envelope for the developer expertise: routine tasks do not appear to get a net economic benefit from being paired (defect reduction is missing or, at least, insufficient to balance the time impact)
- People need to learn how to pair effectively: there will be a "gelling" period. The Utah 1999 study indicated overhead for new PP teams could be over 50%.
- Knowledge diffusion/sharing is an obvious benefit: even if PP is economically flat the sharing of knowledge would still make it worthwhile
- There is no hard evidence whether the quality improvement from PP could be equally/better realised by solo programming together with static analysis and/or inspections
- Effective PP does impose some requirements on the participants: it does not suit extreme introverts, for instance. The pair should have good communications, complementary skills and personality. "Complementary" does not mean "identical" - ideally each member of the pair can being something that the other does not to the relationship.
- PP roles are more complicated than a Driver/Observer pair. Role analysis indicates roles such as "Watchmen", "Task Expert", "Spokesperson" - research here is ongoing
- PP is relatively intense due to the need of maintaining shared focus, and cannot be carried out as a full-time activity. Recommended levels vary: "Uncle" Bob Martin says 50-70%
All of this would seem to indicate that Pair Programming should be concentrated on the tasks that will bring most benefit: these will typically be where the subject matter or implementation context is new to at least one team member. This will maximise the benefits from shared attention and knowledge sharing.