Pomodoro, Ping-Pong or Pair-mate?
This post was written by Maya Rosecrance, Software Engineer at Pivotal London and Sarah Connor, Software Engineer at Pivotal London
Pair programming is at the center of everything we do at R&D at Pivotal. The Redis team pairs every single day with two keyboards, two mice, two monitors, and one computer. We have no remote members, and for the most part there is only someone that ‘solos’ when we have an odd number of people for the day. The benefits of pairing are undeniable as context is shared more easily and two pairs of eyes result in less mistakes and higher quality code. However, sometimes pairing can be uncomfortable, or pairs can have an uneven level of experience or context, or, simply, the pair can be mismatched in terms of assertiveness and personalities. It’s something that we usually don’t take much time to reflect on other than a throwaway comment of the flavor that the driver/navigator balance in the pair was off. The next day, the pair will split up and possibly not match up again for another week so the conversation can be easily lost. In order to force ourselves to have these conversations and to reflect on our pairing culture, we ran an experiment over two weeks.
The Experiment
Every day, we chose one of five techniques and used it for the day. These techniques were inspired by this blog post by a former Pivot.
The goals:
- More evenly split time driving and navigating.
- Provide a structure for less assertive drivers.
- Enable faster context sharing. Often, when one pair member has more context on a portion of the codebase, they would dominate the driving possibly leaving the navigator lost as to how to move through the codebase.
At the end, we had a full team retrospective to discuss the effectiveness of each technique.
Pairing Roles
Pair programming traditionally involves two people acting as either a driver or a navigator. The driver is the person with their hands on the keyboard and the navigator is the person that provides a birds eye view of the direction of the work. The benefits and distinctions separating the work dynamics in this way have been widely discussed. Each of these techniques focused on the transition point between the roles.
Techniques:
Pomodoro
The dependable study technique, Pomodoro is where a timer is used to signal the switch between pairs and taking breaks. Typically this is 25 minutes of work followed by a 5-minute break.
Pros:
- Breaks make a natural reflection point on the existing work.
- It’s the technique with least mental overhead to determine pair switching.
- Both people in pair take snack, bathroom, and phone breaks at the same time.
Cons:
- Requires an external app or browser plugin that needs to be setup.
- Timers are by nature noisy which can be disruptive to the office at large.
- Forced breaks can interrupt pair flow.
We found that this pairing technique had very wide applications but there was mixed feedback on the breaks themselves. One member found that they initially felt the breaks were disruptive but as the day progressed, they felt more natural.
Ping Pong
The classic Ping Pong technique where one person writes a failing test, they switch roles, then the other tries to implement the minimum necessary code in order to pass the test. They will then write the next failing test and the cycle continues.
Pros:
- Works well with TDD.
- Gamifies the coding process.
- Affirms what the last person did and ensures the pair are both on the same page.
Cons:
- Hard to apply when the piece of work does not involve tests.
One of our favorite techniques for pairing when doing TDD, but sadly not easy to use for operations oriented work.
Switch on Google
Switch any time the pair wants to research something further. This is also meant to help reduce the impulse to separate and research individually.
Pros:
- Very useful as a hybrid addition to task-list or ping pong when one of those went on too long.
- Can be applied to switch on a lot of things: new theory, visit to third party tool, opening the manual, etc.
- Indicates that the driver has reached the end of their understanding.
Cons:
- Requires cognitive overhead to know when to switch as pairs would forget to switch or had difficulty splitting up long research pieces.
- Difficult to use for low complexity stories.
Taking the switch on Google in a literal way proved to be disastrous for one pair as they found that Google searches came either far apart or quickly in sequence. The technique proved especially useful during exploratory stories where neither pair had a lot of knowledge or context. It also helped to alleviate the strain involved in researching as a pair as neither person was driving for too long.
Task List
The pair decides on a set of tasks that need to be accomplished and switch after each task is accomplished. Tasks can be created, modified, or deleted as the pair progresses.
Pros:
- Very agile way of working on a story.
- The task list is helpful as documentation.
- Forces the pair to break down the story into bite-size pieces of work.
Cons:
- Not all tasks are of similar size or scope so can lead to unbalanced pairing.
- If the task list is too long, it may be difficult to glean information from it.
A universally applicable technique for stories. We found the discussion around forming the tasks to be a big strength of this technique and led to more thought out approaches.
Pairmate/One-keyboard
A small item like a stuffed animal or tchotchke can be used to signal who is navigating. The navigator holds the item to signal that they are not to touch the keyboard until that item is passed off to the other. Alternatively, the item can be removed altogether and the pair shares a single keyboard which they pass back and forth.
Pros:
- One keyboard version is very strict as the navigator is not able to impulsively grab the keyboard.
- Allows the driver to learn the navigator’s keyboard shortcuts.
Cons:
- Easy to forget to pass the token back and forth. The keyboard solution did not have this as an issue.
- Frustrating at times if the navigator has to dictate something they could accomplish quickly but is not easy to communicate.
We found the one keyboard method to be more applicable than token passing. It was the most dogmatic technique of the bunch but because of it strictness was the most effective in allowing reflection of our practice of pairing. It was also very frustrating at times.
Conclusion
Overall, the pair programming experiment was useful in allowing us to reflect on our dynamics and individual approaches to pairing. It enabled us to understand better how to approach our pairing and gave us techniques to get over the awkward pauses that arise when one person is at a natural stopping point but still has their hands on the keyboard.
For more information or access to the assets used in this blog click here.
Credit for Redis Dino mascot: Denise Yu
Change is the only constant, so individuals, institutions, and businesses must be Built to Adapt. At Pivotal, we believe change should be expected, embraced, and incorporated continuously through development and innovation, because good software is never finished.
What’s the Best Way to Pair? was originally published in Built to Adapt on Medium, where people are continuing the conversation by highlighting and responding to this story.
