Ping-Pong Pairing
The foundational pairing style
In my last post I discussed how pair programming is misunderstood in software engineering today, and recounted my story of how I started with the practice. I also made the case for the use of pairing styles as a learning framework — namely, a means to introduce those who are new to pair programming in general.
In this post, I cover Ping-Pong Pairing and its benefits. I consider this pairing style foundational as it holds the key to learning a number of principles that set us up to be effective pair programmers throughout our careers.
Origins
At the start of this month, I launched a technical coaching program at work. Pair programming lies at the foundation of the program. The program is also geared to software engineers of all skill levels, so the content and approach must accommodate those who are entirely new to pair programming. This begged the question:
How do I teach pair programming to those who have never truly experienced it before?
Fortunately, I am not the first to encounter this problem. When Corey Haines started running coderetreats, he realized that the commonly-adopted practice of Driver-Navigator pair programming is actually an intermediate-level practice. He observed that introducing this pairing style to beginners would often backfire:
Unfortunately, too often this [Driver-Navigator] form of pair-programming leads to what I call the “Driver-Twitterer” style of collaboration. In this mode, the person with the keyboard is writing code while the other person watches intently for a short time. Then, after a bit, the navigator starts to lose interest. Perhaps the driver isn’t talking, perhaps the navigator doesn’t want to disturb them. Sometimes I’ve seen where the driver says “just a second, I’ve got an idea,” and then proceeds to code in silence for minutes on end. This can have the effect of boring the navigator. So, what do they do? Naturally, they check twitter. Or email. Or some other non-code-focused task.1
In response to the lack of communication, Corey introduced ping-pong pairing at his coderetreats. By design, this style of pair programming encourages a high degree of communication.
First Form
There are two forms of ping-pong pairing; the first form is summarized below:
Essentially, one person is responsible for writing tests, while the other is responsible for writing and refining the implementation that makes them pass.
I have found this form very effective at getting someone started with Test-Driven Development (TDD). In my experience, one of the most common obstacles to writing tests lies with the software engineers who have never seen how TDD works in practice. This form of ping-pong pairing is the most effective way to nip this in the bud. Simply assign the software engineer with more TDD experience to the “Test Redder” role.
More broadly, this form of ping-pong pairing is the single most effective way of explaining the value proposition of TDD to another software engineer. When I first looked at code that was written using TDD, I thought it was wasteful. I noticed that codebases written using TDD had at least three lines of test code for one line of implementation code.
Only once I experienced TDD did I recognize the value of the approach, and how it goes far beyond simply achieving test coverage. I finally understood what it meant to refactor in confidence, as opposed to in dread. I also discovered the joys of working with code that is refactored continuously.
While such comments might give you a hint, words alone will always be ineffective in explaining the value of TDD to another software engineer. A better way is to try this first form of ping pong pairing with them for a few red-green-refactor rounds. I recommend a code kata to start, but there’s no reason why it can’t be done when working on shipped code (i.e. code that goes to production).
Second Form
The obvious limitation of the first form of ping-pong pairing is the lack of experience that the “Test Greener” gets in writing tests.
In theory, timer-enforced role-switching addresses this. In practice, however, I’ve rarely seen this work. Once a software engineer gets in their flow-state, they try to maintain it for as long as possible. People who are new to pair programming feel that switching roles threatens their flow-state. In actuality, I’ve found that flow-state can be preserved while still switching roles.
It does require some experience with pair programming to accomplish this. If you wish to work on maintaining your flow-state while switching roles, that is precisely what you need to practice doing! Consequently, the second form of ping-pong pairing has role-switching “built-in”. See below for a summary of the approach:
Essentially, one person gives up control by writing a failing test. You can think of it as “ending your turn” in a similar way you would do for a card game: writing a failing test is like drawing a card from the card pile.
For those new to the ping-pong pairing style, I like to start off at the first form with myself in the “Test Redder” role. I then introduce the second form once we have a good rhythm going. Once I feel that this has been established, I wait until they ask me to write the next failing test. At this point, I say:
Now let’s change things up a bit. Keep control for a little while longer. You write the next failing test, and I will get it to pass.
Once they write the failing test and hand control over to me, I follow the previously-mentioned steps: make the test green, refactor the implementation, and finally, write the next failing test. Once I hand control back to them, they realize that we’ve shifted from the first form of ping-pong pairing to the second.
The second form of ping-pong pairing yields all the benefits of the first form, in addition to a seamless means by which control is handed over from one person to another. This ultimately allows for both participants to have equal exposure to all three parts of the red-green-refactor cycle.
Wrap-up
In a follow-up post, I will discuss three core aspects of pair programming that ping-pong pairing highlights and reinforces the importance of. In the meantime, I encourage you to try out the two forms of ping pong pairing by starting with the first and easing into the second when you and your pairing partner is ready.
Understanding the 4 Rules of Simple Design by Corey Haines