While it’s a common misconception that software engineering is a solitary field, in reality, collaboration often helps you solve programming issues more quickly and efficiently. In this article, we’ll examine the practice of pair programming, highlighting its prominent benefits and potential 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. You can do this collaboration either in person or remotely, in which case you’ll need software for screen sharing and real-time editing.
In pair programming, the developers interchange between two roles. The “driver” writes the code, and the “navigator” reviews the written code while providing information and instructions. You typically alternate roles between every 15 minutes to 1 hour.
Many organizations are still hotly debating pair programming; 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 overall 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
Usually, the partners for pair programming are 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.
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.
