BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Dos and Don’ts of Pair Programming - Study Suggests Togetherness and Expediency for Good Sessions

Dos and Don’ts of Pair Programming - Study Suggests Togetherness and Expediency for Good Sessions

This item in japanese

A recent study by researchers from the Institute of Computer Science of the Free University of Berlin analyzed pair programming (PP) sessions from 13 companies. The study concluded that togetherness and expediency associate 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 only little research into the elements that make pair programming work.
[…] The overall goal of our research is to understand how ‘good’ and ‘bad’ pair programming sessions differ. Ultimately, we want to provide actionable advice for practitioners.

The study named two characteristics of good pair programming sessions. The first characteristic, togetherness, is explained as the ability of good pairs to establish and maintain a common mental model during the session. This may involve one participant being acutely aware of the understanding of the task by the other participant and being able to address the relevant discrepancies. The second characteristic, expediency, implies balancing addressing the immediate matter at hand with the longer-term goals of the pair programming sessions (e.g., onboarding, knowledge transfer).

The researchers provide an example of pair programmers that are able to backtrack together to the original topic after some misunderstanding:

Early in the session, a simple question by J1 interrupts an explanation by J2, which leads to a misunderstanding that takes almost two minutes to clear up. […] Both partners explicitly switch back to the original topic […]:

J2: “There is the central [News] plugin and multiple processors which each handles one wave. […] It checks how the file size is changing.”
J1: “In what time window are you looking?”
[… two minutes of misunderstanding …]
J1: “30 seconds, that’s what I wanted.”
J2: “That’s 30 seconds long, the time window. Now I got you. I can show it to you [in the code] in a minute.”
J1: “Yes. And the NewsPlugin is doing what in all of this? Does it do exactly this monitoring and the delegation to the individual wave plugins, or what?”
J2: “No. The NewsPlugin basically only does—it gets called periodically by the cron server […]”

The study also identified three pair programming anti-patterns: Getting Lost in the Weeds, Losing the Partner, Drowning the Partner. The first antipattern involves spending time investigating irrelevant details and losing track of what is important. Losing the Partner refers to situations in which one participant focuses on the task at hand and does not pay attention to whether the other participant understands what he is doing. The last anti-pattern is somewhat the opposite behavior: one participant explains too much his thoughts and actions, at the expense of expediency.

There has been considerable discussion in the industry about whether to pair program in the first place, in what context it is appropriate to do so, and how best to do it. Jacek Sokulski, a software architect with a postgraduate diploma in psychology, recently mentioned last year in an InfoQ article that the effect of pair programming on software quality may differ according to the task complexity. Wes Higbee, consultant and author of the book Commitment To Value: How to make technical projects worthwhile, cautioned in another InfoQ article (Pair Programming Is No Panacea):

And when it comes to selecting a method, that should be up to the people doing the work. No methodology produces results if the people applying it don’t know why they’re applying it.

The full study details the adopted methodology and data samples. It also contains examples for each pair programming pattern and anti-pattern singled out by the researchers.

Rate this Article

Adoption
Style

BT