This post details behaviours* that were observed during my pair programming studies and were considered to be either undesirable when pair programming or symptomatic of novice pair programming. I have called these two “Thrasher” and “Divider”.
The “Thrasher”
It is hard to think of a programming problem that does not have more than one possible solution. A necessary part of the software development process is to assess the suitability of a particular strategy and select the most appropriate approach. Of the pairs I studied, novice pairs suggested and counter-suggested almost twice as much as those experienced at pair programming. My ethnographic field notes also suggest that novices often thrashed between different strategies, depending on who was driving. The ‘thrasher’ occurs when the programming pair is unable to agree on the approach to take. It can occur at any level of abstraction – from issues like naming and the use of parentheses to the overall design of the solution.
Symptoms include: Very frequent role changes; Physically appropriating the keyboard; Deleting or over-writing code just entered by the other person; Rarely discussing without typing code; The driving continuing to type, ignoring the navigator’s suggestions.
Consequences Include: Making no (or very slow) progress; Producing disjointed code; Irritating one another and those who are nearby; A reticence to continue pairing.
Refactored solution: The pair refrain from typing until a mutually acceptable solution has been agreed. If this is not possible, third party intervention could be requested, ideally from a more experienced developer.
The “Divider”
On many software development teams there is some time pressure. In addition, each partner in the programming pair may have different areas of specialism, which vary in their relevance to different parts of the solution. Therefore, it may seem less time-consuming to divide up the problem space, each focus on a sub-task and then pool the results when they are finished. In fact, in the pairs I studied, experienced pair programmers very rarely worked in this way (rather they compensated for this extremely high level of collaboration by taking regular breaks).
Symptoms include: The pair not sitting together; The pair not engaging together on one task at hand; The pair consistently performing obviously different tasks (e.g. One typing in code while the other draws a diagram or looks up an example); The pair not talking to one another.
Consequences Include: Additional effort integrating the two parts of the solution; Disjointed solutions; Minimising learning opportunities and knowledge distribution; Failure to reap some of the benefits of pair programming (Reduction in errors caused by confirmation bias; Apprenticeship and learning; Lowering the risk from having a single point of expertise; reviewing work for mistakes; peer pressure to perform at one’s best)
Refactored solution: The pair take a collaborative approach to the problem, working alongside one another on all aspects of the task at hand. In particular, each partner contributes to, and is involved in conversations about, almost every sub-task performed at every applicable level of abstraction.
* I am reticent to call them anti-patterns as they were not derived using the accepted manner. However I found adopting a pattern-like way of expressing them was very useful.
Agile in the Wild 
1 Comment