10 Years of thinking about Pair Programming

Last week I gave a TalkShop at Bath Scrum Users Group that summarised my research on pair programming, touched upon relevant findings in the fields of Cognitive Psychology / the Psychology of Programming and provided some opportunities to try out some different modes of pairing.

Here is a  PDF version of the slides, although they are Zen style, so may not stand on their own without explanation.

One (rather embarrassing) thing that I found on the night was that I could no longer name the companies that I studied from memory. Checking back, there were 9 projects across 4 companies, namely: LogicaCMG, Egg, BBC and BNP Paribas.

The findings presented were as follows (spoiler alert if you are planning on attending one of my sessions and would rather do the exercises blind to minimise influencing):

1. Common with other studies (in particular Dunning and Kruger), expert pair programmers under-rated their abilities whereas novices over-rated. This is discussed in more detail in a previous blog post.
2. Experienced Pair Programmers speak significantly less than novices. This makes sense when we consider that talking assists us in solving step-by-step logic problems (as shown in the work of Michelene Chi and many others), yet hinders our ability to obtain creative inspiration (named “verbal overshadowing” by Schooler). Even more so when we contrast this with the knowledge that programming is neither solely hierarchical nor globally opportunistic (as shown in studies by Davie, Green, and Gilmore). One might imagine then that the helpful self-explanation assists us with the more step-wise hierarchical parts whereas being quiet during the opportunistic parts is useful to avoid verbal overshadowing.
3. Pairs almost entirely collaborate rather than co-operate. That is, they work together on each small aspect of the task at hand rather than taking a divide and conquer approach.
4. Not only are a very small number of utterances spoken by a programming pair about syntax and spelling (just 2%), these are distributed pretty evenly between the driver and navigator. Thus implying that, contrary to suggestions (e.g. Williams & Kessler (2003) “ The navigator…observes the work of the driver, looking for tactical…defects. Tactical defects are syntax errors, typos..”), pointing out spelling mistakes is not a significant part of the navigator’s role.
5. The navigators did not talk at a higher level of abstraction than the driver. Rather they both spoke at roughly the same levels of abstraction. Thus implying that, contrary to suggestions (e.g. Kent Beck (2000) “While (the driver) is busy typing, the other partner is thinking at a more strategic level”) the navigator’s role is not defined by them doing more strategic thinking.
6. I suggest some alternative possibilities: i) The fact that both navigator and driver speak most at an intermediate level of abstraction may provide some “cognitive glue” to help gel together the real world and programming domain. ii) Speaking may provide clarification by transforming our sometimes sloppy and incomplete mental models into verbalisations. iii) Speaking at an intermediate level primes the navigator to take over. Solving programming problems, typing and talking all at once is an incredible cognitive load to bear.
7. One of the benefits of verbalisation is that others on the team overhear. I was surprised how this prompted changes in pair composition. It was a mechanism by which others could ‘tune in’ to things that interested them, or via which that the pair could subtly request help (sometimes by simply mentioning someone’s name).
8. There is a system of distributed cognition shared between the team. Verbalisation is only part of this shared mental model. Often informal external representations (e.g. paper sketches, shared rough whiteboard designs etc.) play a key part in this model. A team or pair that are visibly sketching ideas feels like a good ‘smell’ to me.

I also shared my top pairing tips, which can be found on slide 24.

I will blog about them separately in more detail.

Advertisement