Pair programming without keyboard

Pairing in general—and pair programming in particular—is an essential practice of XP . Unfortunately, pairing is closely associated with coding. Take, for example, the definition of the driver role: it is the person in control of the keyboard (Beck 2005). However, pairing is a technique that can—and should—be applied to a wide range of development activities, including, but not limited to, analysis, design, coding and testing. In fact, as noted by (Williams and Kessler 2002), when applied to analysis and design, it has been reported to be most effective (Williams et al. 2000, Allen 2001).

Pair programming, priming and substitution

But why is pairing strongly associated with coding in practice? In “Thinking, Fast and Slow,” Daniel Kahneman provides an account of how people generate intuitive opinions of complex matters (Kahneman 2011). For example, people tend to give an answer more easily to the question of “How happy are you with your life?” if they were primed by another, related but simpler question, like “How many dates did you have last month?” Kahneman calls this process substitution.

Getting the design of a software system right is a daunting task. It is hard to even define what good design is. Many concerns must be balanced, and a single flaw can have serious consequences . Furthermore, design is a highly creative endeavor: each design problem is unique and requires holistic thinking.

On the other hand, getting the code right is much easier. Why? Because there are lots of heuristics and patterns available (Bloch 2017, Beck 2008), that, once learned, can be applied over and over. For example, once you learn to watch out for bad variable names, you can spot them quickly and address the issue locally. Although not purely mechanical, this activity takes relatively little mental effort. This is not to say that naming is unimportant, nor that it is trivial – good naming just does not make up for bad design. In words of Russell Ackoff alluding to Peter Drucker, “doing the wrong thing right is not nearly as good as doing the right thing wrong.”

Whiteboard first

Having said that, what do you do about it? If you are like me—and you get uncomfortable whenever you are asked to pair at the keyboard without a clear vision of the design—step up and pair at the whiteboard first. Usually, this helps a lot. You are still pairing, but armed with the right tool. This makes it less probable for the substitution heuristic to kick in. In other words, pairing at the whiteboard enables you and your peer to think about the problem more clearly and gain a better shared understanding of the problem domain, without being fooled by your brain into thinking that you are making progress by dealing with secondary issues like code formatting, variable naming, implementation patterns, and so on.

In conclusion, pairing is a powerful technique that is not bound to coding, as in pair programming. Sometimes, pairing at the whiteboard is more effective than pairing at the keyboard, because it lowers the risk of finding the right solution to the wrong problem.

References

• Beck, Kent, and Cynthia Andres. Extreme Programming Explained: Embrace Change. 2nd ed. Boston, MA: Addison-Wesley, 2005.
• Williams, Laurie, and Robert Kessler. Pair Programming Illuminated. Boston: Addison-Wesley, 2002.
• Williams, L., Robert R. Kessler, W. Cunningham, and R. Jeffries. “Strengthening the Case for Pair Programming.” IEEE Software 17, no. 4 (2000): 19–25. https://doi.org/10.1109/52.854064.
• Allen, Adrian. “An Investigation into Potential Reasons Why Pair Programming is Not Widely Adopted by Programmers as a Standard Development Practice When Developing Software.” Technical Report. University of Cape Town, 2012.
• Kahneman, Daniel. Thinking, Fast and Slow. London, England: Penguin Books, 2012.
• Bloch, Joshua. Effective Java. 3rd ed. Boston: Addison-Wesley, 2017.
• Beck, Kent. Implementation Patterns. The Addison-Wesley Signature Series. Upper Saddle River, NJ: Addison-Wesley, 2008.