Behaviors To Avoid When Practicing Pair Programming

When two people get together to write code on a single computer, it is given the name of pair programming.

Pair programming was popularized by the eXtreme programming book by Kent Beck, in there he reports the technique to develop software in pairs which spiked the interest of researchers in the subject. Lan Cao and Peng Xu found that pair programming leads to a deeper level of thinking and engagement in the task at hand. 

Pair programming also carries different approaches. There are different styles of pair programming, such as the drive/navigator, ping-pong, strong-style, and pair development.

All of them are well described by Birgitta Böckeler and Nina Siessegger. Their article describes the approach to how to practice each style.

Here, we will focus especially on only two of them: the drive/navigator and ping-pong, as it seems that both are the most commonly used.

The objective is to have a look at what should be avoided when developing software in pairs.

First, we briefly introduce each pair programming style, and then we follow the behaviors to avoid.

Driver/Navigator

For my own taste, the driver and navigator are the most popular among practitioners. In this style, the driver is the one that is writing the code and thinking about the solution in place to make concrete steps to advance in the task at hand. The navigator, on the other hand, is watching the driver and also giving insights on the task at hand.

But not only that, the navigator is the one thinking in a broader way, and she's also in charge of giving support.

The communication between the driver and navigator is constant. This style also is the one that fits well with the Pomodoro technique.

Ping/Pong

Ping-pong is the style that "embraces the Test Driven Development" methodology; the reason behind that is the way in which that dynamic works. Let's assume we have a pair that will start working together, Sandra and Clara. The ping/pong session should go something similar to the following:

• Sandra start writing a failing test
• Clara makes the test to pass
• Now, Clara can decide if she wants to refactor
• Clara now writes a failing test for Sandra
• The loop repeats

It is also possible to expand the ping/pong to a broader approach. One might start a session writing a class diagram, and the next person in the pair implements the first set of classes.

Regardless of the style, what is key to the success of pair programming is collaboration.

Behaviors To Avoid

Despite its popularity, pair programming seems to be a methodology that is not wildly adopted by the industry. When it is, it might vary on what "pair" and "programming" means given a specific context.

Sometimes pair programming is used in specific moments throughout the day of practitioners, as reported by Lauren Peate on the podcast Software Engineering Unlocked hosted by Michaela Greiler to fulfill specific tasks.

But, in the XP, pair programming is the default approach to developing all the aspects of the software.

Due to the variation and interpretation of what pair programming is, companies that adopt it might face some miss conceptions of how to practice it. Often, this is the root cause of having a poor experience while pairing.

• Lack of soft (social) skills
• Lack of knowledge in the practice of pair programming

In the following sections, we will go over some miss conceptions of the practice. Avoiding those might lead to a better experience when pairing.

Lack of Communication

The driver and navigator is the style that requires the pair to focus on a single problem at once. Therefore, the navigator is the one that should give support and question the driver's decisions to keep both in sync.

When it does not happen, the collaboration session might suffer from a lack of interaction between the pair. The first miss conception of the driver/navigator approach is that the navigator just watches the driver and does nothing; it should be the opposite.

As much communication as possible is a sign that the pair is progressing. Of course, we haven't mentioned the knowledge variance that the drive and navigator might have.

Multi-Tasking

Checking the phone for notifications or deviating attention to another thing that is not the problem at hand is a warning that the pair is not in sync. The advent of remote pair programming sessions might even facilitate such distraction during the session.

The navigator should give as much support as possible and even more when the driver is blocked for whatever reason. Some activities that the navigator might want to perform:

• Checking documentation for the piece of code that the driver is writing
• Verifying if the task at hand goes towards the end goal of the task (it should prevent the pair from going into a path that is out of scope)
• Control the Pomodoro cycle if agreed

On the other hand, the driver is also expected to write the code and not just be the navigator's puppet. When it happens, the collaboration in the session might suffer, leading to a heavy load on the navigator.