Before focusing internally on the pair themselves, I* wanted to understand the impact of the environment within which the programming pair work. The questions I wanted to explore were: Did the pairs and their teams make use of or benefit from their surroundings? And if so, how?
Given the previous studies had shown six months to be as good a line as any to draw regarding pairing expertise, I studied pair programmers with 6 months or more pairing experience on 9 projects across 4 different companies. Using ‘Grounded Theory’ based research, I recorded a total of 24 one-hour pair programming sessions (videoing where possible, audio where not). I took field notes whilst recording the sessions and supplemented the data with informal interviews and photos. I also transcribed and analysed 14,886 sentences (I know that’s an insane amount but it seemed like a good idea at the time!).
Here are the first couple of things that jumped out from the data:
Pair programming can be intensive
Whilst almost all of the programmers voluntarily chose to pair for core hours, few were able to sustain pairing all day every day. Rather, the day consisted of a mixture of non-paired activities (checking email, going to meetings, making and taking telephone calls), core but not formally fixed pair programming hours and regular breaks. This not only allowed people to attend to activities not related to current coding, but also compensated for the fact that pairing can be intensive and tiring.
Pair programming raises peripheral awareness
All of the teams worked in an open-plan environment. This allowed the team to ‘overhear’ each other and pick up on useful or relevant information. In fact, the high level of conversation when pair programming means that much more information is transparent to the whole team, which might otherwise be hidden. Overhearing a pair’s conversation not only allowed others to tune in to relevant information but also allowed a pair to highlight information that might be relevant to others. Here are two real examples. In both of them (not their real names) Andrew and Betty are pairing and Zoe is overhearing.
Example 1:
Betty: “Whenever he’s free we’re….”
Zoe (overhearing): “He’s free now”.
Andrew: “Is he?!”
Example 2:
Betty: “Yeah, that was in..(sighs)..package one, wasn’t it? And it’s not here, so it needs to go into package two I think.”
Andrew: “Ok, so that’s something we can make (raises voice) Zoe aware of”.
Zoe (overhearing): “What’s that?”
Andrew: “Ummm….something which was, I think, in <package name>, which has just been abolished.”
Zoe: “Right, yeah. It’s going to be constantly evolving, unfortunately, isn’t it?”
Overhearing sometimes resulted in a third person joining/helping the pair for a while. Occasionally this resulted in the pairing changing, with an existing member ‘swapping out’ with someone else with specialist knowledge. This fluid re-pairing is really interesting as it is contrary to the static, more formal nature of pair allocation typically described in the pair programming literature.
In the next post we will take a look at the surprising way that pairers use the artefacts around them to help in their pairing.
*In conjunction with my supervisors Prof. Benedict du Boulay and Dr. Pablo Romero and with kind funding by EPSRC
Agile in the Wild 
This is fascinating and matches my experience with pair programming. I don’t believe you can achieve optimal pair programming with a definite set of rules and procedures. However, it may be best to continue studying and possibly come up with a set of guidelines that work for most developers and situations.
Have there been studies about pairing in other disciplines?
Tim, I am serialising some research I did around 10 years ago to make it more widely accessible, hence there are quite a few more studies and findings to come. I hope you find them equally interesting and useful. I have compiled a list of pairing behaviours (not quite patterns as they didn’t follow the approved pattern harvesting process) that came out of my research and will include that in a later post. Yes, absolutely pairs have been studies elsewhere. Notably in aircraft piloting (pilot/co-pilot model).
Thank you for formulating these insights. We have experienced these, yet some are not even aware that a “third person” is contributing and making a difference.