The benefits of pair programming: will it work on your team?

What is Pair Programming?

When you read the word “programmer,” what is the first image that pops into your mind? It would not be unusual if you imagine one person, sitting at a computer, fingers flying on a keyboard. That is a typical way for developers to write software, but it’s not the only way.

Pair Programming, also called pair coding or just “pairing,” turns software development into a team effort. Instead of one person writing code, two people collaborate in real time. One developer, the “driver,” has his/her hands on the keyboard and actually writes the code. The driver speaks as she works, sharing her thinking in real time. The other developer acts as “navigator,” watching the driver as she works. The navigator makes comments and suggestions as the driver writes the code. Pair programming isn’t new, but it is often associated with the Extreme Programming (XP) movement.

If you are a developer, and you’ve never tried pair programming, this may seem a little strange, perhaps even off-putting. Pair programming is quite different from solo programming. It may sound a little weird, but it does have pros and cons.

The Advantages of Pair Programming

Pair Programming is credited with a variety of benefits.

Code Quality Pairs of developers are more likely to catch problems with code quality while working together. While the driver is focused on writing the code, the navigator is free to think about the style and function. Code quality standards tend to be followed more consistently when developers work together in pairs.

Robust Solutions There are many ways to solve problems with software. Developing software involves selecting the best data structures, algorithms, and class hierarchies, among many other decisions. When developers pair, each of these choices can benefit from the experience of both developers, and the dialog they have with each other while making those choices.

Developer Communications Solo development may be great for focus, but keeping developers informed of each other’s work is a chronic problem. Code reviews can alleviate the problem, but pairing prevents it outright. Developers that pair are equally familiar with the code that they write, and the decisions that went into it. Teams that swap pairing partners regularly maintain a high degree of communications between all developers on a team.

Knowledge Transfer Pair programming can be an excellent way for junior programmers to learn rapidly from more senior developers. Juniors and interns experience a sort of “full-immersion” in software development when pairing. They learn the entire complex process, not just by watching, but by participating.

Culture The “high-bandwidth” communication of pair programming often leads to a team with great personal chemistry and a distinct team identity. Positive cultural experiences are correlated with higher rates of employee satisfaction. This is a distinct advantage in an industry where talent is expensive and scarce.

The Disadvantages of Pair Programming

Pair programming has benefits, but it’s not a panacea, and it’s not for everyone.

Higher Costs It follows logically that two developers using one keyboard multiplies development costs. Studies have shown a 15% - 100% increase in baseline development costs. While these costs may be offset at least in part by increased quality and less rework, teams considering pairing must account for potentially higher initial development costs.

Mixed Results Studies on pair programming have not returned conclusive evidence of measurable benefits. That doesn’t necessarily mean you can’t derive benefit from it, but you’ll have to determine want you want from pairing and how to measure your success.

Team Fit The high-intensity communication of pair programming is not a good fit for every personality. Drivers are supposed to “develop out loud,” speaking as they write code. Introverts may not be keen on the idea of sitting, literally shoulder-to-shoulder, with a colleague for six to eight hours a day. Some developers, especially experienced ones, are legitimately more productive when working solo. Senior developers may not be eager to lower their output while pairing.

“Watch the Master” Pairing two developers with a significant experience gap can be beneficial to both, under the right circumstances. However, it can also lead to the more experienced developer dominating the process. The novice developer then becomes disengaged, “watching the master” work. The dialog between developers slows to nothing, and most of the touted benefits of pair programming are lost.

Getting Started: Pair Programming Tips

If your team is considering pairing, there are several steps you can take to prepare.

The first thing to do is talk about it as a team. If the team consensus leans toward a lot of discomfort, a large-scale trial of pairing is probably not a good idea. Start small with developers that are willing to try it out, then let them share their experiences. Reluctant developers may be swayed, at least to try it, after hearing about direct experiences from colleagues.

Your physical workspaces can be configured to be pairing-friendly. Two developers, crammed into a typical one-person cube with a curved space for the computer, is a very uncomfortable configuration. Use desks and computer configurations specifically set up for pairing to make it feel natural. Developers shouldn’t have to physically move to switch between driver and navigator. Computers set up with a shared mouse, keyboard, and monitor also make things more convenient.

As you try pairing, experiment with different modes and pair combinations. Some pairs stick together for a week or more, others swap every day. Some developers may prefer the driver or navigator role, or prefer to switch back and forth depending on the situation. Developers on a team will have different backgrounds and levels of experience. Try various combinations of both to determine what works best.

Get the team together for a debrief on a regular basis and get honest feedback. What is working, and what isn’t? The transition from solo programming to pairing is likely to be intense, and feel very different from the status quo. Create a psychologically safe environment where developers can share their feelings about the process, without having to worry about offending colleagues or management.

Pairing doesn’t have to be all-or-nothing. Some companies swear by pair programming, and organize their entire development organization around it, though that is rare. Use pairing where it makes a measurable difference. Don’t force it on developers who find it uncomfortable.

Pair Programming Examples

Here are two example scenarios for pairing:

Example 1: Two Experienced Developers Bob and Jody are both senior developers for ACME Corp. They have been with the company for about the same length of time, and have similar levels of experience in software development. Jody is gregarious and talkative. Bob is more reserved, and struggles with speaking while driving.

Bob and Jody make a great pair because they understand each other’s strengths and weaknesses. Jody drives more often because she likes to speak while coding. However, she knows that she has a tendency to overwhelm the process. She tries to be mindful of this, and make sure Bob remains engaged by asking questions. Bob challenges himself by driving at least half the time. If he gets quiet, Jody will ask a question or make a suggestion.

Example 2: One Senior, One Junior Alex and Jess are developers for ACME Corp. Jess is a senior developer and has been with the company for years. Alex is an intern. Most of his experience in software development is in his work at university.

Alex and Jess work well together because Jess has experience pairing with junior-level developers. She uses both driving and navigating as teaching opportunities.

Driving is an obvious chance to demonstrate coding techniques, however, there are tricks Jess can use to enhance Alex’s learning experience. Sometimes, Jess will deliberately introduce an anti-pattern into her code. Knowing that he’s expected to catch these anti-patterns keeps Alex engaged.

Jess teaches through navigating by asking questions at least twice as often as she makes suggestions. Alex learns that if she’s still asking questions, he’s probably missing something. If he gets stuck, Jess will make suggestions to guide him in the right direction.

Related Resources

https://en.wikipedia.org/wiki/Pair_programming

https://www.agilealliance.org/glossary/pairing/

http://www.extremeprogramming.org/rules/pair.html

https://blog.codinghorror.com/pair-programming-vs-code-reviews/

https://builttoadapt.io/what-its-like-to-pair-for-a-year-86d048494324