What is pair programming? What is it good (and bad) for?
Q: What is pair programming?
A: Two programmers, working together at a single computer. One writes the code, the other reviews it. In the process, they (supposedly) produce better, cleaner, faster code through collaboration.
But does this approach really work? The answer is both yes and no.
Pair programming, in some circumstances, can be massively helpful for the development team. But, like many “best practices”, what sounds great on the tin doesn’t work in every practical application.
So, here’s a simple overview of pair programming, and what it’s good (and not so good) for in agile software development.
Pair programming: the set-up
Pair programming starts with a small, well-defined task in mind. Two programmers will then join forces to complete that task together in a tag-team of sorts.
Programmer A is your “driver”. The driver actively operates the workstation, controlling the keyboard as they write lines of code. They’re focused on the micro-challenge that each line of code presents, rather than on any larger issues. Think tactics and details, not strategy. As they code, they’ll talk through what they’re doing and explain their thought process.
Programmer B is your “navigator” or “observer”. The navigator watches the driver at work, acting as an on-the-fly reviewer. They’re focused on bigger-picture factors such as issues, next steps, potential upcoming problems, etc. Think strategy, rather than tactics. So, the navigator will make comments, add suggestions, and offer guidance to the driver as they code.
Then, every twenty-thirty minutes or so, the driver and the navigator will swap roles for a fresh perspective. They’ll do this until the task is complete – usually for several hours per day.
So, what is pair programming good for?
The promise of pair programming is that it promotes quality code in a more collaborative development environment. Its proponents list several key benefits.
Fewer code defects
With two pairs of eyes on the screen, minor code errors are less likely to remain unobserved. The odds are, a navigator will spot the typo or bug that the deeply concentrating driver missed. Indeed, one study found that pair programming leads to code with 15% fewer defects.
Knowledge sharing
Pair programming can be an effective way to upskill developers on areas they’re less experienced in. For example, you might pair a developer new to Vue.js with one who has worked with the framework for years. That way, knowledge is diffused by doing – with real-time support and guidance.
Collective code ownership
It’s notoriously hard to work with another developer’s code. A developer working on a shared company codebase will often have their job cut out trying to ascertain why certain decisions were made. Pair programming, then, helps alleviate this problem. It takes code production out of its one-person silo. And, in so doing, it promotes consistent, collective standards.
Improved team communication
Communication is another notorious issue in software development teams. Coding can be a solitary task – usually conducted in total silence. So, pair programming is an effective way to encourage a more communicative development environment, with better team chemistry. Tasks are completed via joint efforts, rather than in isolation. This works particularly well when programmers regularly swap paired partners.
Sharp focus
In paired programming, the driver doesn’t have to second-guess every line of code to worry about bugs or future problems. Nor does the navigator have to dive into the detail of writing code. Instead, each can maintain their own area of focus. In turn, they power through tasks faster and more efficiently.
Innovation
Just as there is no single or “right” way to go about writing a think piece, there is no single or “right” way to go about writing code. So, when developers pair, they each bring a unique outlook to the problem at hand. By swapping their ideas and feeding off the expertise of the other, then, they may often land upon innovative solutions that neither would have thought of alone.
What is pair programming not so good for?
For all these benefits, pair programming doesn’t always work as desired. Though it sounds great in theory, its utility can sometimes devolve in everyday practice.
Many coders hate it
First, not every coder will feel comfortable with pair programming. Since development is typically performed in silence, it can be jarring or even frustrating to have to explain every step and every thought process as you’re still actively working through it. Similarly, not every developer is going to feel comfortable criticising the work of others in such close proximity. (Literally sat shoulder to shoulder for several hours.)
Stymied flow
Having to explain everything and talk through every line of code also impedes a creative flow. Constantly stop-starting, and constantly talking about every decision, can be counterproductive. It can also be harder to concentrate when you’re waiting for feedback and input on the fly.
Disengagement
Watching someone else at work isn’t always an engaging task. This is particularly true in instances where junior developers are paired with senior developers, and end up simply “watching the master” without having anything to add. This inevitably leads to disengagement. Which, in turn, undermines the touted benefits of shared knowledge and improved team chemistry.
Increased costs
With two developers working the same task simultaneously, you’ll end up expending more man-hours to achieve the same goal. It’s not quite twice the cost – as there will be fewer mistakes later down the line – but coding costs will still naturally rise during paired programming.
Lack of self-review
Paired programming removes the opportunity for the driver to review their own code. With a navigator watching over your shoulder and spotting every issue for you, you can’t sit back and evaluate your own work reflectively. In time, you may even lose this skill altogether as you come to expect others to check your code.
Team dysfunctionality
Often, experienced developers will be more productive when simply left to their own devices. They may prove irritable if they have to slow down and explain everything they’re done. And when you pair two experienced developers together, you also risk a clash of egos. Since there’s no right way to code something, you could hit a standstill with both developers wishing to push their own ideas.
Paired programming in review
So, what is pair programming? To offer an alternate answer to the one provided at the start of this article: it’s the Marmite of the agile software development world. Some love it, some hate it, all have decidedly fixed opinions on their own correctness.
Is it worth giving a chance? Absolutely.
Will it definitely work for your organisation? You’ll need to work at it and see.
