A recent study by researchers at the Institute for Computer Science at the Free University of Berlin analyzed the pair programming (PP) sessions of 13 companies. The study concluded that usability and timeliness are associated with good pair programming sessions.
Franz Zieris and Lutz Prechelt, the authors of the study, explained their motivation as follows:
While there is some awareness in the literature that two developers are not suddenly more productive just because they are placed next to each other, there has been little research on them. elements that make programming in pairs work.
[…] The overall objective of our research is to understand how “good” and “bad” pair programming sessions differ. Ultimately, we want to provide actionable advice to practitioners.
The study named two characteristics of good pair programming sessions. The first characteristic, unity, is explained by the ability of good couples to establish and maintain a common mental model during the session. This may imply that one participant is fully aware of the understanding of the task by the other participant and is able to remedy relevant deviations. The second characteristic, timeliness, involves striking a balance between addressing the immediate issue and the longer-term goals of pair programming sessions (eg, integration, knowledge transfer).
The researchers provide an example of couple programmers able to come back together to the original subject after a misunderstanding:
At the start of the session, a simple question from J1 interrupts an explanation from J2, which leads to a misunderstanding that takes nearly two minutes to resolve. […] Both partners explicitly return to the original subject […]:
D2: “There is the central [News] plugin and several processors which each manage a wave. […] It checks the evolution of the file size. “
D1: “What time window are you looking at?”
[… two minutes of misunderstanding …] D1: “30 seconds is what I wanted.”
D2: “It’s been 30 seconds, the time window. Now I got you. I can show it to you [in the code] in a minute.”
D1: “Yes. And the NewsPlugin does what in all of this? Does it do exactly this monitoring and delegation to the different wave plugins, or what?”
D2: “No. The NewsPlugin only does this – it is called periodically by the cron server. […]”
The study also identified three anti-pair programming models: Getting lost in the weeds, Losing the partner, Drown the partner. The first anti-model is spending time investigating irrelevant details and losing track of what’s important. Losing the partner refers to situations in which one participant is focused on the task at hand and is not concerned with whether the other participant understands what they are doing. The last anti-pattern is a bit of the opposite behavior: a participant explains too much their thoughts and actions, to the detriment of opportunity.
There has been a lot of discussion in the industry about whether to pair the program in the first place, in what context it should be done and how best to do it. Jacek Sokulski, a software architect with a postgraduate degree in psychology, recently mentioned in an InfoQ article last year that the effect of pair programming on software quality may differ depending on the complexity of the task. . Wes Higbee, consultant and author of the book Commitment To Value: Comment valuing technical projects, warned in another InfoQ article (Pair programming is not a panacea):
And when it comes to choosing a method, it should be up to the people doing the work. No methodology produces results if the people who apply it do not know why they are applying it.
The full study details the methodology adopted and the data samples. It also contains examples for each pair and anti-pattern programming pattern chosen by the researchers.