If you are working in the software development field, chances are you've already heard about pair programming. But even though most people know about the technique, many developers have never actually tried it or even understood its benefits.
Pair programming is simple: two people, one computer. But some people will read this sentence and automatically translate that to "waste of time and money." Are they wrong? Well... mostly.
When you take a flight to enjoy your vacation in a sunny and beautiful place, two people are inside the cabin to make sure that nothing goes wrong during your trip: pilot and copilot. Why? Because humans make mistakes and are not guaranteed to work properly 100% of the time. So having a copilot makes perfect sense. Or would you rather pay less for a flight without a copilot?
Pair programming became very popular in the software development industry because it helps us to reduce the amount of mistakes developers make. Often, the later you discover a problem, the bigger it gets. And unlike some professions, developers need to deal with the consequences of their own mistakes at all times. That's why pair programming conquered the hearts of many developers around the world and started to spread in a bottom-up fashion throughout companies all around the world a couple of decades ago.
How Pair Programming Works
Even though the concept of pair programming is quite simple (two people and one computer), we can apply this concept using different strategies, and the best strategy for you will depend on which benefit your team wants to leverage the most. For example: the driver and navigator approach suggest that one person (the navigator) won't touch the keyboard/mouse while the other person (the driver) will focus on implementing the necessary code. In summary: the driver will focus on the micro details while the navigator will pay more attention to the big picture.
But at the end of the day, no matter the strategy you use, the point is to have conversations about what's being done. Some teams would rather go to a room, put the code on a big TV screen, and spread some wireless mouses and keyboards around so the whole team can code together and discuss the implementation while they are doing it.
You can even do pair programming as a virtual team. The driver-navigator mode is easily achieved by just having the driver share the screen in any video-conference platform, such as Zoom, Teams, etc. If you want more interactivity, some tools, such as VSCode, have plugins that allow multiple people to edit the same code file. But remember: it's not about the tools, it's all about having good conversations.
Benefits of Pair Programming
One of the greatest outcomes achieved by teams that do pair programming is knowledge sharing. After all, a team that is always learning is unstoppable! Especially when they learn together and from each other. For example: a less experienced developer can learn a lot from a more senior developer if the latter is acting as the navigator in the driver-navigator model. However, if the senior developer assumes the driver position all the time, it could be harder for a less experienced person to follow what's happening with the code.
Another great benefit is how early a team can spot bugs and errors just by having an extra pair of eyes on the code while it's being written. Spontaneous discussions about the implementation strategies will emerge more often and sooner, saving time that would later be spent on integrations and extensive code reviews.
After all, the most efficient and effective method of conveying information to and within a development team is face-to-face conversation, isn't it?
A great way to start doing pair programming is actually just trying it. But if you happen to have a scrum master around, then it could be even better! Having someone experienced to coach both programmers into how to do pair programming properly can be a game changer and a way to ease the learning curve.
Pair Programming in Practice
Pair programming isn't perfect. It consumes time, reduces privacy, and can be quite tiring when practiced for longer periods of time. We must also take into consideration who the people are doing pair programming: their culture, their personal preferences, and their mental availability to do so. Having an agreement about personal space, breaks, and how to reach such agreements is really important to avoid situations where one (or both!) of the participants feels disrespected.
It might sound obvious, but it's worth noting that if people start to feel uncomfortable with pair programming, they will stop doing it. It's harder to perceive a power dynamic when you are practicing pair programming, and having a skilled facilitator could really help the pair to become productive and comfortable sooner.
The Pomodoro Technique is a good way for the pair in question to manage themselves. They can use the tool to work for 25 minutes and then take a break, during which the programmers can have some time to themselves. Once they return, they can change the roles between driver and navigator for the next 25 minutes. This kind of mechanism can be particularly useful for remote pair programming sessions, as video sessions tend to be more mentally taxing and require longer and more frequent breaks.
Pair Programming and Code Review
Some people see pair programming and code review as rivals, and they couldn't be more wrong. In some places, pair programming with an occasional code review will suffice. And in some other scenarios (like in most open source projects), the team will have to work with pull requests and mandatory code reviews.
It's impossible to establish a best practice because the decision is context-dependent. The only bad decision is blindly following a process just because someone said so. Try, experiment with it, and learn empirically by practicing constantly.
Studies and Findings on Pair Programming
Since pair programming isn't exactly a new idea; there are a lot of studies about the impacts generated by this technique. Alistair Cockburn and Laurie Williams found out that people working in pairs are often way faster than individuals when it comes to developing a solution, debunking the common argument that pair programming doubles the development costs. It does increase the initial development costs, but only by 15%. It also reduces the defect rate by 15%. They also managed to perceive improvements in code quality and the overall satisfaction of the developers who participated in the research.
Try Pair Programming to Learn Faster and Collaborate
At the end of day, agile is about learning. Learning about the product being built, the relationship between customer and product, and also the software development process that best suits the context and human beings involved in it.
Pair programming is a way to learn faster and collaboratively, so... what's not to love? If you watch and deal with the power dynamics, don't overdo it and constantly reflect on the way you're doing it, then there's little chance that it won't generate some great impacts for your team.
Subscribe to Scrum Alliance to Learn More
If you're interested in hearing more tips and insights from experienced agile practitioners, please subscribe to Scrum Alliance emails. We're out there practicing agility in real-world scenarios just like you, and we look forward to sharing what we've learned so you can elevate your practice.
References:
https://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF
Get the latest resources from Scrum Alliance delivered straight to your inbox
Subscribe