Win a free ticket to the 2020 IoT Innovator Summit in Austin, TX.

Subscribe to our blog to get the latest articles straight to your inbox.

It’s a common misconception that software engineering is a solitary field. As in most endeavors, teamwork can help you solve programming issues more quickly and efficiently. In this article, we’ll discuss the practice of pair programming and some of its most important benefits and drawbacks.

What is Pair Programming?

Pair programming, as the name suggests, is a software development practice in which two programmers collaborate on a single workstation at the same time. This collaboration can be done either in person or remotely, in which case you’ll need software for screen sharing and real-time editing.

There are two alternating roles for developers to play in pair programming. One programmer acts as the driver who writes the code, and the other acts as the navigator who reviews the code and provides information and instructions. Both parties switch off roles at regular intervals, anywhere between 15 minutes to 1 hour.

For many organizations, pair programming is still a hotly debated practice; some adopt it wholeheartedly, while others outright refuse to consider it. In the next two sections, we’ll discuss the advantages and disadvantages of pair programming to understand each of these viewpoints.

The Pros of Pair Programming

1. Fewer mistakes and bugs

Software developers usually work alone, which can cause negative traits like stubbornness and tunnel vision. It’s all too easy to get stuck when trying to fix a bug based on an incorrect assumption, a hidden typo, or a gap in your knowledge.

When you’re pair programming, however, you’re forced to work as a team. This automatically gives the code more “quality control.” Both partners use their shared experience and knowledge to solve problems faster as they arise. According to a study by the University of Utah, code produced during pair programming has 15 percent fewer defects.

Having a partner on hand also lets you practice techniques like “rubber duck debugging.” This debugging method asks you to explain your code in the simplest terms line by line, as if speaking to a cute yet uninformed rubber duck. Your partner can more easily spot your own misconceptions and biases, helping you get back on track more quickly.

2. Greater resiliency

The “bus factor” should be a concern for all mature software development teams. If one person gets hit by a bus, or needs to suddenly depart for some other reason, what will happen to the project? Is there valuable technical knowledge that would be forever lost (or take a long time to recover) because only one person knows about it?

Pair programming does much to resolve this concern. At least two people should be familiar with every part of the code base, rather than information living with only one person. This helps prevent unexpected project slowdowns and delays due to staff turnover.

3. Increased code quality

Sharing best practices between partners leads to better code. In particular, having to be accountable to your partner discourages both members from taking any shortcuts or hacks. Pair programming encourages teams to build robust solutions that won’t create unexpected bugs later on.

4. Faster training

The partners for pair programming are usually two experts or one expert and one novice. In this latter case, pair programming allows junior and new team members to pick up information from their more experienced colleagues. This can massively speed up the onboarding process.

5. Improved team morale

Finally, pair programming gives you someone else to talk to on the project who can empathize with you and help you solve your problems, so that you aren’t stuck spinning your wheels all day. This helps make the team as a whole more productive and happier. 96 percent of people who practice pair programming at work say that they enjoy their job more than when programming alone.

The Cons of Pair Programming

1. Higher costs

Having two people working on a single initiative may seem like a waste of valuable resources. Indeed, it’s true that pair programming won’t be able to complete a project in half the time.

Still, the greater overhead that pair programming incurs is typically balanced by the higher-quality code and a more efficient, effective final result. You pay more in costs upfront, but you can recover your investment over the lifetime of the project, since you’ll spend less time maintaining the codebase.

2. Sustainability

Pair programming isn’t usually sustainable enough to be practiced all of the time. The ideal amount of time to spend pair programming seems to be around 2 to 2.5 hours—and don’t forget to take breaks!

The good news is that you can take measures to break up the intensity of pair programming. Try switching to a new project or a new partner throughout the day to help keep your mind fresh.

Conclusion

Pair programming isn’t new; it’s been around the software development industry for decades. As a practice, pair programming originates from the extreme programming (XP) methodology, which prioritizes high software quality and frequent tests and releases.

For some organizations, pair programming simply isn’t the right fit for their situation. However, a growing number of companies are finding that pair programming has a variety of benefits, including saved development time, higher-quality code, and better training and onboarding. As a result, everyone on the team is working together to build the most successful, best version of the product possible. To learn more about how we work here at Very, contact us.