Lennon and McCartney. Penn and Teller. Venus and Serena.
Some of the greatest achievements in history were produced by pairs of great minds working side-by-side on the same task. Software is no exception.
At Pivotal/Tanzu Labs, we are known for being on the cutting edge of Agile software development—some might even say extreme. One software development technique in which we believe deeply is pair programming.
Pair programming helps the team produce high quality software while also helping everyone on the development team have a broader understanding of the software. There are some challenges to pair programming but we’ve proven time again across hundreds of projects that the benefits far outweigh the costs.
In this article, you will learn to:
Pair programming is a software development technique whereby two programmers work on the same problem, at the same time, on the same computer, with the goal of producing high quality software quickly.
Regarding “on the same computer,” we do not mean two people hunched over a tiny laptop. When co-located, we recommend setting up two large monitors, two sets of keyboards, two mice, and two sets of anything else the pair needs to work effectively together, such as a laptop docking station.
If the pair is not co-located, remote pair programming is a good alternative. Remote pair programming is pair programming with the help of commonly available collaboration software.
“Done” does not mean the developers have committed their code and lifted their fingers off their keyboards. For Pivotal/Tanzu Labs, “done” means low-defect software delivered to users in production that does not need rework due to errors or missed requirements. Pair programming helps accomplish this mission in the following ways:
The most beneficial outcome of pair programming is the quality of the code written by the team. As pairs switch (often daily), everyone has a chance to contribute and refine the system they are developing. Benefits include:
While pair programming does support shipping high quality code to production quickly, predictability is a more important benefit over speed. Radical swings in delivery velocity introduce risk into the development cycles — pair programming helps mitigate swings in delivery velocity in the following ways:
While pair programming, not only are two people working on the same difficult problem together, they are also constantly teaching one another in the following ways:
Individual ownership of features, modules, and even entire systems is both common and tempting – it’s comforting to know someone is responsible for something important. This pattern is also extremely risky since people switch jobs, have life events that make them unavailable, and other factors that impact delivery velocity. Pair programming mitigates these risks in the following ways:
Pair programming isn’t all about the code — it’s also all about the people who write the code.
The benefits of pair programming are clear, but those benefits don’t come cheaply. Pairing is hard. Without a doubt, the most difficult challenge of pair programming is the willingness to give it an honest try.
Pair programming means not only sharing what we know, but also exposing how much we don’t know. For many people in the software industry this contradicts the rock-star-ninja-hacker-wizard image bestowed upon developers. Accepting that we all have areas of growth is important for successful pair programming, especially since you and your pair are in the same boat: both of you are sharing what you know and exposing what you don’t know at the same time. By complementing each other’s abilities, you become greater than the sum of both of your skills and experience.
Other challenges include:
While there are many pair programming styles, our experience shows most are a variation of the driver/navigator style. At any given moment, the driver has their fingers on the keyboard, coding and implementing the next logic statement. At the same time, the navigator is looking back at what was just written, suggesting the next course of action, and strategically thinking further ahead. Research shows and our experience confirms that our brains have difficulty performing high-level strategizing and detailed execution at the same time, which is why two heads working together is better than one in complex problem-solving situations. Pairing addresses this conundrum by having one person for each role.
The pair should switch driver/navigator roles on a regular basis. Sometimes this happens organically to create a “balanced” pairing session. We do recommend a few different pair programming formats for those new to pair programming, for pairs finding their driver/navigator time to be unbalanced, or for those who want to introduce variety into their pairing sessions. More details about each of these are in the blog post What’s the Best Way to Pair? by Maya Rosecrance and Sarah Connor.
Just go for it! Sit down, start pairing, and ride whatever driver/navigator pattern emerges. The pair should be disciplined about switching roles, and be cognisant of whether they are falling into an unbalanced driver/navigator pattern.
Pomodoro is a dependable study technique where a timer is used to signal the switch between roles, taking breaks, or even switching pairs entirely. Typically, this is 25 minutes of work, followed by a 5-minute break.
“Ping-Pong” pairing is a natural complement to Test Driven Development (TDD). The classic Ping Pong technique first has the driver write a failing test for some desired functionality that is not yet implemented. The pair switches roles, having the new driver implement the minimum necessary code in order to pass the test. That driver then writes the next failing test and the cycle continues, with each person equally sharing test-writing and functionality-implementation duties.
Switch roles any time the pair wants to research something further. This helps reduce the impulse to separate and research individually, which can sometimes evolve into an excuse to stop pairing entirely.
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 (physically or virtually when remote) to the other. Alternatively, the item can be removed, and the pair shares a single keyboard or toggles remote-keyboard control as needed.
The pair decides on a set of tasks that need to be accomplished and switches after each is completed. Tasks can be created, modified, or deleted as the pair progresses. Ideally each takes about the same amount of time to complete.