There are many different ways that pairs may work together.
I particularly like the distinction made between Collaboration and Cooperation. I tend to explain this using the example given by Kerawalla, Pearce, Yuill, Luckin and Harris (2006) of two people doing a crossword together. They explain that in a collaborative approach both people would work together on each and every clue, whereas using a cooperative (divide and conquer) approach one person might take the horizontal clues while the other considers the vertical clues, stitching them together either along the way or at the end.
Using this distinction, it is possible to analyse the conversations of pair programmers and use the addition of new information to a subtask as an indicator of collaboration on that task. If we have both added new information then we have likely collaborated on that task to some extent.
To find out more about the levels of collaboration and cooperation in the pair programmers I studied, I first reduced the work in each pair programming session into a tree of numbered subtasks. I then analysed the dialogue of the pair for contribution of new information to each sub-task.
Next I generalised out a set of generic subtask types and cross-referenced them with those described in the psychology of programming literature (paying particular attention to Pennington, Lee and Rehder, 1995) so that I could compare between sessions. The task types were (in no particular order):
- Agree strategy / conventions
- Configure the environment
- Write and run tests
- Comment the code
- Correspond with 3rd party
- Compile, build, check code in/out
- Refactor existing code
- Write new code
- Debug/find and fix a defect
- Find/check example
- Discuss the development environment
(As an aside for anyone interested, whilst not statistically significant, a non-parametric Friedman test showed that as a general trend the majority of contributions related to comprehension, and the least common utterances were related to commenting the code).
Over 24 one-hour pair programming sessions, 93% of subtasks had new information contributed to them by both partners. So, if we are using that as a working definition, the pair were collaborating on 93% of their work.
When we dig a little deeper and take a look at the driver and navigator roles we find similar levels of collaboration. If we split the contributions by role there is a slight trend (again not statistically significant) towards the driver (programmer currently typing) adding a little more information than the navigator. As this is slight it could possibly just be due to the driver commentating on what they are doing.
So what does all this tell us? Well, the findings suggest that the benefits derived from ‘pairing up’ on software development tasks are not achieved through a ‘divide and conquer’ approach, but elsewhere.
Next post we’ll look at whether the navigator and driver seem to work at different levels of abstraction (as is sometimes suggested).
Disclaimer: This type of quantitative work is difficult in this domain. There are a number of limitations to this study, some of which are:
- The pairs studied were an opportunistic sample of developers who had been consistently pair programming for more than six months.
- The method of data collections was limited to transcribed verbalisations.
- Other, more subtle means of communication than conversation are excluded from the analysis.
- It was not possible to double-blind code the transcriptions. The highly contextual nature of the transcriptions and the sheer volume of transcribed data (14,886 sentences) made second coding impractical.