How Pair Programming Really Works

Posted by Shane Hastie on Jan 22, 2010

Sections

Process & Practices

Topics

Agile ,

Agile Techniques

Tags

Pair Programming

Stuart Wray, from the Royal School of Signals, wrote a paper for the January 2010 edition of IEEE Software Magazine entitled "How Pair Programming Really Works". 

In the paper he first brings together the various pairing approaches (journeyman-apprentice / driver-navigator) and identifies a common way of working:

My own experience as a developer using pair programming is that it isn’t just a technique where one person programs and the other person watches. Both programmers work closely together, chatting the whole time, jotting down reminders of things to do, and pointing out pieces of code on the screen. (One of the clichés of pair programming is that if you’re doing it right, your screen should be covered with greasy finger-marks by the end of the day.) Programmers take turns at the keyboard, usually swapping over with a phrase like, "No, let me show you what I mean."

 Building on his description of effective pair programming (and identifying that not all implementations of pair programming are effective) he presents four mechanisms that make effective pair programming successful.

Mechanism 1: Pair Programmers Chat

Brian Kernighan and Rob Pike recommended explaining problems aloud, even to a stuffed toy, a practice that John Sturdy called the rubber-plant effect. Part of pair programming’s effectiveness is presumably due to this effect being continually triggered: as one programmer gets stuck, the back-and-forth chat serves to unstick them in the same way as solo programmers talking about their problems out loud.

 

He discusses the increased benefits that chatting brings about where what he calls the "expert programmer theory" applies - where the members of the pair perceive each other as knowledgeable problems are solved more effectively:
 

So perhaps this is how expert programmer theory really works: an expert is more likely to ask a deep question, which prompts the novel inference from the stuck programmer. It also seems possible that merely thinking that you’re talking to an expert - or pretending - will help the stuck programmer produce the sort of deep questions that experts have asked them in the past.

 

Summing up the value of chatting he states:
 

This first mechanism would therefore lead us to predict that programmers who chat about their programs more should be more productive and that those who pose occasional deep questions for each other should be most productive of all.

 

Mechanism 2: Pair Programmers Notice More Details
"You don’t see your own mistakes" is a truism of software development (and many other disciplines). 

Wray links this to theories of change blindness and inattentional blindness.
 

What we notice depends on what we expect to see and what we unconsciously consider salient. So, although successful pair programmers will concentrate mostly on the same things, they might notice different things.

 

So, two people programming together won’t have the same prior knowledge or categorization: one will presumably spot some things faster and the other different things faster. Where their rate of working is limited by the rate they can find things by just looking, two heads must be better than one. And in fact, one of the earliest observations that people make when they start to pair program is that the person who isn’t typing code always picks up typos quicker: :Oh, you’ve left out the comma here."

 

He goes on to warn about the phenomenon of pair fatigue:  When two programmers pair together, the things they notice and fail to notice become more similar. Eventually, the benefit from two pairs of eyes becomes negligible.

 

Pair Fatigue is a driver for rotating pairs regularly:
Some pair programmers regard rotation as an optional part of the practice, and on a small team, or with few programmers willing to pair, there might be little alternative. However, pair fatigue means they’ll ultimately be much less productive.

 

Mechanism 3: Fighting Poor Practices
Peer pressure not to slip into bad practices is a clearly identified benefit of effective pair programming.

He discusses the example of "code-and-fix" programming and links it to the addictive nature of slot machine gambling:
 

This is the special property of interactive programming that makes it difficult to do the right thing. With code and fix, we tinker haphazardly with our programs, effectively putting a coin into the slot machine each time we run our code. Slot machines are known as the most addictive form of gambling, and the similarly unpredictable rewards from code-and-fix programming mean that it could be equally addictive.

 

Pair programmers might be less susceptible to poor practices because they can promise to write code in a particular way and ensure that each other’s promises are kept. The prevalence of two-people working in jobs where human fallibility is a serious problem should lead us to seriously con¬sider that pair pressure might be the solution for us, too. 

Mechanism 4: Sharing and Judging Expertise
The productivity differences between individuals are vast, measured to be at least a factor of 10.  This often means that estimates of difficulty and time are inaccurate.  This applies to both good and bad programmers - you can only determine someone’s programming capabilities by working closely with them.

 

Most programmers work on problems on their own, so no one knows how good (or bad) they really are. But with pair programming, people continually work together. Because they keep swapping pairs, everyone on the team learns who’s the most expert at particular things. From this comparison, they also realize their own level of expertise. We should therefore expect more accurate estimates of time and difficulty by a pair programming team than from a solo programming team. From my experience, this does appear to be the case.

 

---

What techniques and mechanisms make pair programming effective in your environment?

InfoQ has more Pair Programming content here. 

Shane Hastie is an agile coach, trainer and consultant working for Software Education in Australia & New Zealand

1. Back to top

   Really nice article - i enjoyed the read.

   by Oliver McPhee

   Hi Shane
   
   Really nice article - i enjoyed the read.
   
   I especially agree with this...
   "You don’t see your own mistakes" is a truism of software development (and many other disciplines).
   
   And that point alone can save you so much time & hassle with later bug fixing!
   
   These are the paired programming best practices we are using at the moment:
   Paired Programming Best Practices
   
   Cheers,
   Ollie

   Reply

• Older >