Although it’s one of the oldest practices in agile development, pair programming is less common today than other pillars of agile, such as scrum and iterative development.
Steve Smith, founder of Ardalis Services, a software development consulting company, and co-instructor of a Pluralsight course on pair programming, told Built In that the practice originated as way to do instant code reviews.
“It comes from extreme programming, which was one of the first agile practices that came about back in the 1990s,” Smith said. “It’s well known that code reviews help find and reduce defects in code that you’re shipping, and the sooner you discover a defect, the less expensive it is to fix. And so it makes sense to do at least some amount of your new development in pairs.”
The original idea was that having another developer present during the development phase makes it easier to catch and fix mistakes even while they are being made. But the benefits of pair programming extend well beyond catching coding errors.
“The intent is to develop software more effectively,” Smith said.
Pairing Helps Developers Make Better Design Choices
Coding with another developer can be helpful during the design phase — particularly for complex projects.
“When there’s design involved and you don’t know how to solve the problem yet, and you’re thinking about the ways to solve the problem — which is most of real software development — it can make a lot of sense,” Smith said. “You have someone that you can bounce ideas off of and help with things like: ‘What should I call this? How should we name this? What about using this design versus that design?’”
Software development can involve a great deal of decision-making at every step in the process, he said. Even for development teams that follow the top-down waterfall methodology, where every architectural detail is mapped out before any code is written, it’s hard to avoid making coding choices during implementation.
“What should I call this? How should we name this? What about using this design versus that design?”
“After you’ve got a complete specification of exactly how everything’s going to be done, then you just throw it over the wall to some developers and they just code it up — works great in theory, but rarely works like that in practice,” Smith said. “You’re uncovering new requirements as you’re implementing things, you’re iterating rapidly.... One developer is worried about these few lines of code inside a method inside a class, and, meanwhile, the other developer might be thinking: ‘OK, what other classes do we have to modify as part of this change? What test cases might we need to right now?’”
When running into these choices, it can help to talk things through with another person. Pair programming ensures that another developer is always available as a sounding board, and eliminates any worries about disrupting another person’s flow.
“And so you save up these questions until you have some team meeting or you just don’t worry about it and pick something — and now you’ve missed an opportunity to collaborate,” Smith said. “Maybe you end up with a suboptimal solution, because your teammate knew a better way to do it but you never talked to them.”
Talking About Problems Begets Better Solutions
There’s a somewhat tongue-in-cheek practice in software development known as “rubber ducking,” where developers keep actual rubber ducks on their desks to act as surrogate listeners. The idea is that a developer can explain their conundrum to the duck when they run into coding problems — often, the simple act of putting the problem into words will help them reach a solution.
“The term I’ve coined over the years is ‘forced verbalization,’” said Edward Hieatt, senior vice president at VMware. His company acquired Pivotal Software, whose developers exclusively used pair programming to develop software, early this year.
“The process inside your head is, ‘problem-solve, problem-solve, change this, fix this,’ — it’s very quick,” Hieatt said about a developer’s approach to programming when working alone. “You’re kind of implicitly defining a problem and knocking it down a few lines of code.... And [sometimes] you don’t realize at the time that you’re doing it, that you set a trajectory to get into a rat hole.”
Talking about these decisions out loud, even with a rubber duck, can give the developer space to consider whether their approach makes sense. But the reason developers still work in teams instead of alone with a team of ducks is that other developers make much better sounding boards.
For one thing, a rubber duck will never ask questions.
How to Get Started With Pair Programming
It’s unusual for companies to exclusively use pair programming to develop code. But Hieatt, who has employed pair programming for the past 20 years, first as a developer and then as a manager of developers who exclusively pair program, is an enthusiastic proponent.
“We in the software development industry are well behind as leaders in defining how to work,” Hieatt said. “We are overly reliant on the hero culture of individuals coding really fast and the open-source culture of distributed development, where individuals are contributing at arm’s length. We never really said, ‘Look, here’s what a good team looks like,’ so all the practices we do tend to seem extreme. I’ve got a very strong point of view [that we should] do various practices full out.”
While Hieatt is in favor of pair programming for all types of software development work, Smith believes it’s better suited for large, complex projects.
Pair programming is useful for situations “where you’re trying to think about the best way to solve a technical problem,” Smith said. “It’s not great for things where there’s not a lot of complexity, like when we need to update the content on the website ... or when we need to write documentation — it’s probably easier for someone to just go through and make updates to the documentation, and then someone else to come back through and do a proofreading. You probably don’t need two sets of eyes [as you’re] writing it word for word.”
The mechanics of pair programming are fairly straightforward. Pairs usually sit together or share a workstation, although pairing together remotely is also possible using screen sharing or a program like Visual Studio Code Live Share. For those pairing in person, developers can work off a single computer and either take turns controlling the keyboard or plug in two keyboards. Either way, only one developer should be doing the actual typing at a time.
“We in the software development industry are well behind as leaders in defining how to work.”
“If you’re the one typing the code in, you have some idea of the syntax necessary to make this thing work, so you’re pretty much focused just on that,” Smith said. “If you’re not the person having to type, you have a number of things that you’re now freed up to do. You can be thinking about the next thing that you need to work on and what that should look like. You could be watching and helping the person who’s typing, if they don’t know the syntax as well as you do.”
Smith described the pair programming dynamic as consisting of two distinct roles: the developer at the keyboard works at the tactical level, while the other developer considers the code on a strategic level. Every once in a while, the developers should switch roles.
In the Pluralsight course, Smith covers two ways to switch roles. One of the methods, called pingpong pairing, follows the test-driven development pattern by having one developer write tests and the other developer writing the necessary code to get the tests to pass. Another method is to set timers and switch between roles when the timer goes off.
“I think the most important thing is that you do switch roles,” Smith said. “As far as how you decide to switch roles, that’s going to be up to the people doing it and what’s comfortable for them.”
It Isn’t for Everyone, and Who You Pair Up Matters
Strategies for keeping both developers engaged in the process, such as switching roles, can be helpful, but the success of a pair programming relationship depends in part on individual personalities.
“Everything is dependent on personality in life, so I wouldn’t say that this is just a slam dunk to work for anybody,” Smith said. “I think that if you give it a fair shake, it will work for most people. But there are some folks who really don’t want to work closely with someone. It’s very draining for some people to have to deal with someone else for extended periods of time, and they work best when they have time to just focus on their own.”
Smith said that pair programming works best when there isn’t a large skill disparity between the two developers. When both developers are “peers,” they can each bring their experiences and knowledge to the table, and no one is left behind. On the other hand, Smith said that pair programming fails when one developer is doing all the work and the other developer is not paying attention.
“I can just sit there and stare at the screen while they type, and not offer any feedback, not really think deeply about what they’re doing, and not be worried about the next thing,” he said. “When you’re doing it right, it’s engaging for both people, whether you have the keyboard or not, because you should be thinking about the problem — and if it’s an interesting problem, there’s plenty for you to be thinking about.”
Hieatt agreed that disengagement can be a problem, but believes that senior and junior developers can pair program together successfully. In fact, Hieatt’s development team specifically tries to pair individuals with different skill sets together.
“When you’re doing it right, it’s engaging for both people.”
“We’re looking to combine two people who, right now, have the most divergent knowledge,” he said. “And the reason for that is we’re trying to chip away at those differences as quickly as possible, to make everybody as useful as possible.”
Developers are encouraged to pair with a different person each day, which helps break down knowledge silos and spread information throughout the organization. Pair programming also helps with the onboarding process for new developers, which cuts down on designated training time.
“We don’t actually do official training like many companies do,” Hieatt said. “Generally speaking, we throw you into the deep end on a project. And the observation over the years is that it actually works incredibly well.... In general, [new developers] are very effective within a few days, definitely within a few weeks.”
Pair programming is sometimes thought of as a passing fad, but it’s actually an effective way of using team structure to solve common coding and business problems, Hieatt said.
“When you talk to developers about what [they] really should be doing for the business, they start to admit stuff like, ‘Collaborate more, we should be more responsible for quality,’” Hieatt said. “It’s one of the key ways that we try [to achieve] high productivity indefinitely.”
And apart from the practical benefits of pair programming, Hieatt described it as a practice that is intellectually and socially rewarding for developers as well.
“If you talk to senior developers who are used to pairing, they would much rather pair with a junior person than not pair with somebody,” Hieatt said. “I think it’s something about the social dynamic. Just the atmosphere, it starts the conversation going.... There’s something very sacred about two people working together.”
