One of the most common misconceptions about the software developer's work is that it's a solitary job. Just like in many other undertakings, teamwork is an essential element in a software development project. A great team helps to solve programming issues faster and more efficiently. Moreover, team members can learn from each other – that goes especially for pair programming sessions.
In this article, we explore the practice of pair programming to show you its pros and cons and share some best practices that have proven to be valuable to our development teams.
Table of contents:
- What is pair programming?
- Pros of pair programming
- Cons of pair programming
- Pair programming best practices
What is pair programming?
Pair programming is a practice in software development where two developers collaborate in a single workstation at the same time. This collaboration can be done either remotely or in person. If it's the former, programmers will need special software that allows screen sharing and real-time editing to make it all work.
How does pair programming work?
When programming in a pair, developers take two alternating roles. While one programmer is the driver who writes the code, the other serves as the navigator who reviews the code and provides the former with all the key instructions and information.
The idea is to switch these roles at regular intervals that can last from 15 minutes to 1 hour.
While some companies adopt pair programming, others refuse to consider it. That's because pair programming is a practice that comes with some incredible advantages but also disadvantages you should consider before implementing it in your team.
Pros of pair programming
1. Fewer bugs and mistakes
When software developers work alone, they can fall victim to many problems. Tunnel vision or stubbornness in using a specific method for solving a problem – these are just the tip of the iceberg. They might get stuck while trying to fix a bug based on an incorrect assumption. They might have gaps in knowledge or simply make some typos.
In pair programming, two developers are forced to work as a team. And another pair of eyes looking at the code automatically adds more quality control to the process of its writing. Both developers use their shared knowledge and experience to solve problems faster, even immediately after they arise. According to a study from the University of Utah, code developed during pair programming comes with 15% fewer defects.
Having a partner with you while you code also allows practicing techniques like rubber duck debugging. This method of debugging assumes that you explain your code in the simplest terms, line by line – as if explaining it to a cute rubber duck that just isn't very proficient in coding. This allows the partner to easily identify your biases or misconceptions and help you get back on track quicker.
2. Greater resilience
Every software development team should consider this factor in their projects:
If a person gets hit by a bus (or needs to suddenly depart from the project for another – perhaps more realistic – reason) what will happen to the project? Is there any valuable technical knowledge that would be lost forever with that person gone just because they're the only person on the team who has it?
Pair programming eliminates this concern because it means that at least two people will become very familiar with some part of the codebase. The information will never live with only one person, which helps to prevent unexpected project disruptions or delays due to staff turnover.
3. Improved code quality
When sharing best practices with each other, developers get to increase the overall quality of the code. Moreover, when a developer needs to be accountable to their partner, they're less likely to take any shortcuts or use hacks.
Pair programming is a practice that encourages team members to build robust solutions that won't create any unexpected bugs later on and minimize technical debt.
4. Faster training
In pair programming, the partners are usually two mid-level/senior developers, or one seasoned coder and one junior developer. In the latter scenario, pair programming makes for an excellent opportunity for junior or new team members who can pick up a wealth of insights from their more experienced colleagues. As you can imagine, this accelerates the onboarding process as well.
5. Better team morale
Pair programming is an opportunity to talk to someone else on the project. Your partner can empathize with you and help you solve problems, so you're never stuck in your brain the entire day. That's why pair programming makes the entire team more productive and happier.
According to one survey, 96% of developers who practice pair programming at work say that they enjoy their job more than when programming alone.
6. Better knowledge sharing
Paired programming offers a great opportunity for team members to share and exchange their knowledge and experience at coding as they get to learn from their colleagues. It allows developers to receive immediate, face-to-face, and practical teaching. This is far more efficient than online tutorials and faster than searching the Internet for information.
More senior programmers may also teach developers some of those highly valuable but non-written best practices and methodologies. Pair programming serves as a fantastic method for programmers to form mentorship ties.
Moreover, pair programming boosts the interpersonal skills of your employees. Working together on a single project teaches your team the importance of communication and collaboration.
Cons of pair programming
1. Higher development costs
The idea of having two developers working on a single task at the same time seems like a waste of valuable resources. It's true that when practicing pair programming, these team members aren't going to complete a project in half the time.
However, the overhead introduced by this practice balances out thanks to the higher quality of code and better final results. You might pay more up-front, but you can recover that investment over the lifetime of your project because your team will spend much less time on maintaining the codebase and fixing bugs.
2. Sustainability
It's common knowledge that pair programming is unsustainable enough to be practiced all the time. The perfect amount of time developers can spend on pair programming is around 2 to 2.5 hours (including breaks).
To break up the intensity of pair programming, you can simply switch to another project or get a new partner. This helps developers to keep their minds fresh and confront their work with a new pair of eyes.
Is pair programming better than code reviews?
First, let’s explain what code reviews are. Code reviews mean having another programmer look at your code to see if there's anything that might be improved or if there are any bugs. It combines testing and quality control to ensure that your code is error-free.
But here’s the catch: finding someone to evaluate your code might be difficult since individuals may not be so happy to look at another person’s code and understand their logic only to verify the code’s quality.
And pair programming, on the other hand, is like having someone examine your code on a regular basis. So it could be described as a more advanced version of code reviews because two people become familiar with the software. And if one finds a flaw in the other's code, the bug may be fixed right away.
Best practices for pair programming
1. When should you get started with pair programming?
The truth is that every team does pair programming to some extent, even if it doesn't admit to it. Almost every developer out there has a tendency to call others for help when they're stuck on a complex piece of code. That's a form of pair programming as well.
We already said that pair programming helps to solve complex problems faster – so why can't we apply it all of the time? It's just not sustainable over long periods.
If you'd like to get started in pair programming, it's better to do it slowly. For example, during the next sprint, you can try to pair program around 50% of your time. You can also try most programming on specific story points. That way, your next retrospective becomes an opportunity to evaluate your experience in pair programming.
If it works for you, you can start defining the pairing agreement within the team. When doing that, answer these questions:
- For how long will developers be paired?
- How will the pairs be organized?
- How will you distribute stories?
- When should developers switch between the roles of the driver and navigator?
2. For how long should developers pair up?
While in some teams, developers switch pairs every day for half a day, others have completely different approaches. In general, spreading knowledge across all the members of the team is a good practice. However, it doesn't always work as well as we wish. That's because it takes some time for the story lead to onboard partners on the story's objectives and tasks. That's why finishing a story might take slightly more time.
Here's one best practice: switching pairs on a weekly or story basis. You can do that during the sprint – like the mid-sprint planning meeting. That way, you make sure that no pair of developers work together for more than one week.
Another option is switching pairs after closing the story. For example, if during the daily standup developers say that they're close to finishing their story, they could also ask if any pair is interested in switching the partners.
Changing pairs frequently is important for many reasons. It creates a stronger bond between team members and reduces the chance of any conflicts that might emerge when two developers spend too much time working together.
4. When is the best time to plan pairing?
If your team follows the Scrum methodology, the best candidates for pair planning are the sprint planning and sprint review meetings. Once you go over all the pending stories in the sprint, you can agree on the pairs and assign story points to each pair.
5. Keep things moving
Ship code as frequently as possible. This is a general best practice that doesn't go only for pair programming.
Make sure that the pairing is dynamic by switching between the navigator and the driver frequently. If you don't do this, you risk losing the navigator's focus and engagement in the story. Writing code in pairs can be an excellent incentive for team members to switch between the driver and navigator frequently, especially when your developers are paired remotely.
6. Update everyone on stories
It's a good idea to keep an up-to-date document shared between all the team members that includes all of the story information. This document can be in the form of a word document, SharePoint, a to-do list, or even a mind map. The important thing is that you share this information with the entire team.
Pair Programming - Wrap up
Pair programming isn't a brand-new practice. It's been around in the software development industry for decades. While for some organizations, pair programming doesn't fit well, others find that it brings them many benefits, including higher quality code, better training, and faster onboarding. As long as everyone in the team is working together towards the same goal, pair programming is a good idea.
Do you know any other benefits or challenges of pair programming? Did we miss anything here?
Give us a shout-out in the comments and share your stories of pair programming. Did pair programming help you become a better developer? Did it teach you some important skills? We're very curious to learn how the practice of pair programming impacts anything from a developer's daily life to career development.
