Patterns of Pairing

In the early days of extreme programming, a number of patterns emerged that served to coordinate how two developers worked together. They probably came about because the concept of pairing was new, and most programmers weren’t used to anything other than working alone. Some of these patterns deal with issues specific to colocated pairs, but a few have carried over into remote pairing.

Tag Team

In this pattern, programmers take turns as the driver, who is in control of the keyboard, and the navigator, who contributes to the task verbally. The pair can alternate between these roles at preset time intervals or in an ad hoc fashion. In both cases, the driver writes code while the navigator acts as a reviewer and/or foreman. As reviewer, the navigator is responsible for identifying any mistakes the driver makes at the code level. As foreman, the navigator is responsible for thinking strategically about the overall structure of the code base and whether the code is solving the business problem at hand.^[96]

Ping-Pong

This pattern is an extension of both the tag-team pattern and test-driven development. The process begins with a programmer writing a test to define some new behavior or replicate a bug. The test will fail because it’s new, at which point the first programmer passes control to the second programmer, whose job is to make the test pass. Throughout the process, both programmers communicate and discuss the problem, but control of the mouse and keyboard is strictly divided between the two phases.

Let the Junior Drive

This pattern assumes one programmer is a novice and the other programmer is significantly more experienced. For the entire session, the more experienced programmer acts as the navigator while the less experienced programmer acts as the driver. It’s important to note that some experts consider this an antipattern, as it can slow down the session by restricting fluid interaction between programmers. That might explain why studies conducted on real pairing sessions at large-scale companies find the boundaries between these roles break down in practice—resulting to an approach more similar to tag team than anything else.^[97]

Parallel Pairing (aka Buddy Programming)

In this pattern, two programmers work independently on the same problem and converge at the end to compare solutions and ultimately merge them. In this way, it mimics the difference between concurrency and parallelism in computer systems. Parallel pairing is not truly pairing, but it does have the advantage of eliminating many of the technical challenges described in this book because developers work independently for the most part.

Trio Programming

This includes any scenario in which more than two programmers attempt to work together on the same piece of code. Most of the tools discussed in this book, including tmux and VNC, support sharing with multiple users. In both cases, the host starts a session as normal while multiple clients connect to the session from distinct machines. As with the tag-team pattern, only one person acts as the driver during the session, but there will be multiple navigators. Thus, it’s important to clearly define each person’s role when implementing this pattern. Trio programming is often used when pair programming is strictly enforced (that is, solo programming is forbidden) but the team has an odd number of members. The disadvantage of this pattern is that each programmer gets less time to drive than would be the case with fewer people in the session. For this reason, many organizations discourage it. Joe Moore calls it an antipattern.

By most accounts, experienced pair programmers don’t use these patterns—at least intentionally. The programmers at Test Double, Pivotal Labs, Big Nerd Ranch, and several other companies describe a typical pair-programming session as being largely unstructured. If they follow any pattern, it might best be described as an ad hoc tag-team pattern. These programmers are experienced enough at pairing that they don’t need the rigidity of strict patterns. But there are a some exceptions.

“Ping-pong is great in interviews [and] in coaching situations,” says Justin Searls. “In an environment where [no one] has done pairing before…[I’m] a little more formal and I start with ping-pong so that people have good prompts for what’s next.”

As you remote-pair-program, begin to use the ping-pong pattern. It will give you and your partner clear cues that help you learn when to switch roles. As you become more comfortable, move on to the tag-team pattern with preset intervals. Switch to the ad hoc tag-team pattern only when you begin to feel that you can comfortably anticipate the need to switch roles. You may end up loving or hating these patterns, but in either case you’ll learn more about what works and what doesn’t when pairing remotely. After time, you’ll develop your own methods and patterns that work for you and your organization.