TL;DR

• Pair programming is a development technique where two developers work on one workstation at the same time, with one taking on a more active role and one offering review. 
• There are different models of paired programming, including ‘Driver and Navigator’, ‘Ping Pong Developing’ and more unstructured models, each with their own purpose and challenges. 
• Benefits of the model include an increase in code quality, a sharing of knowledge, a boost to wellbeing and new opportunities for hands-on training and mentoring. 

How many developers does it take to change a lightbulb? None, that’s a hardware problem. 

For none-joke related work, developers will often find themselves working solo, even as part of a wider team. But the industry is starting to embrace the concept of pair programming, along with the benefits to productivity, performance and developer wellbeing the setup can bring. Check out our summary below. 

What is pair programming?

Pair programming is an Agile software development technique where two developers work together on one workstation at the same time. Traditionally that means one computer, monitor, keyboard and mouse, but two developers. Don’t worry, you’re allowed two chairs, as well. 

Each developer takes on a certain role for a specified amount of time, usually a hands on/hands off format, before the roles are switched. The basic premise behind it is that two sets of eyes are better than one. With code being designed, written and tested by two people simultaneously, the aim is a general reduction in errors thanks to a closer review process. It’s the ‘measure twice, cut once’ of the development world. 

Types of Pair Programming 

There are a few different models when it comes to pair programming: 

• Driver + Navigator: The most well-known model is to have two clearly defined roles which each developer takes in alternating ‘shifts’.
  • Driver: The driver is the one with their hands ‘on the wheel’. They operate the computer and physically write the code, ideally explaining out loud the process whilst taking advice from the navigator. 
  • Navigator: The navigator is a more passive role in which the developer watches over the driver as they write code, taking a wider, more strategic view of the work and offering advice or guidance when they spot potential for errors.

Having the guidance and backup of the Navigator essentially frees up the Driver to focus more on the granular, tactical parts of writing code. The roles are switched frequently (could be every 15 minutes or once every hour), in order to keep both developers engaged and energized. 

• Ping Pong: This structure combines Paired Programming with another development technique: Test Driven Development. In ‘ping pong’ style paired programming, one developer writes a test, then the other developer writes enough code to make it pass. The flow becomes a rapid passing of the work from one developer to the other – the software essentially becomes a ping pong ball. 

• Unstructured: An unstructured format of pair programming where there are no set roles but a loose collaboration style. This might work better for two developers when one has much less experience to offer the duo, but doesn’t offer the efficiency of the other models. 

• Remote pair programming: Thanks to the accessibility of collaborative work tools and remote desktop sharing, it’s perfectly viable to develop as a pair even when you’re not literally at the same desk. As long as you have the right communication tools, any of the above models can work for remote developers, too. 

Benefits of pair programming: 

• Fewer mistakes: The most obvious benefit of this model of work is that it can lead to significantly less errors in code. With the increased quality control of having a navigator, code will be of higher quality with less mistakes to fix later. A study from the University of Utah found that code produced in a pair had 15% less errors than code produced individually. 

• Higher quality: Having a partner that you are accountable for, as well as having two minds working on the same problem, generally lessens the temptation to ‘cut corners’, and can lead to higher quality, more robust and reliable code than a single developer might produce. 

• Resilience for the team: With two people working on a project, the burden of knowledge is taken off one person’s shoulders. If it came to an unexpected absence or people moved on, there will be someone else with intimate knowledge of the work, negating the stress of having significant gaps in knowledge. 

• Morale: Working collaboratively and closely can improve morale and lead to an increase in wellbeing at work. In fact, in an online survey of paired programmers, 96% of them stated they are happier working this way than alone.

• Mentoring and onboarding: Pair programming offers a unique opportunity for training, with different structures to consider for different purposes. You might want to pair a novice developer with a skilled veteran to show them the ropes with a hands-on project, giving them the security of a mentor and also providing oversight on their work. Alternatively you might want to pair two novices together as a test in which they can help each other succeed. 

Limitations: 

Of course no work model is perfect, and pair programming isn’t right for every situation. 

• Willingness: Not every developer likes working in such a close-contact way. Pair programming works best with two developers who have the soft skills required for true collaborative working, and could lead to a decrease in morale if ‘forced’ upon more introverted colleagues. 

• Efficiency: Having two people working on one section of code is clearly a time-consuming prospect, and inevitably is less efficient than spreading the two developers across different tasks. However this drawback is usually offset by the increased quality of code and the decrease in errors. 

• Sustainability: Pair programming is not an efficient way to work 100% of the time. Whilst the model has clear and measurable benefits, the cost of having two developers working in this way full time would be huge. Instead it seems best to organize paired work in daily shifts, integrated into a normal working day. 

Despite the above challenges, the benefits of pair programming are clear, with a positive outcome for quality of work, the ownership of knowledge, and the wellbeing of the developers. Interested in collaborative work? Check out our top tools for collaborative work here!