RDEL #13: The case for (and against) pair programming
What are the benefits and costs, and when does it makes sense to consider implementing it?
Welcome back to RDEL! Each week, we pose an interesting topic in engineering leadership, and apply the latest research in the field to drive to an answer. (BTW - We’re publishing RDEL #13, on the week of Friday the 13th, in October 🕸️ 🦴 🎃).
👨💻👩💻 This week, we look to a programming practice that has been widely debated for years - pair programming. It seems each company has a different opinion on the value of pair programming (personally, I’ve been in engineering orgs that have polar opposite opinions on whether to implement it). So, what’s the case for (and against) pair programming?
The context:
Pair programming is a practice in which two software engineers work together on a single software implementation. It originated from Extreme Programming, introduced by Kent Beck as a famous aspect of the Agile framework. Generally, one engineer is driving the code writing process (driving), while the other engineer is asking questions, navigating implementation, or making suggestions (navigator). There are also other styles of pair programming, such as ping-ponging back and forth.
Unlike more commonplace programming practices like code reviews, pair programming sees a broad range of perspectives on whether or not it is a worthwhile practice. For example, a team at Thoughtworks assessed the benefits and costs of pair programming for their own organization - their answer to whether to pair program was: “Sometimes - but give it a chance”. (Their arguments are much more detailed than that, and I highly recommend the read!).
With so many diverse perspectives on pair programming, its useful to turn to the research lens - our favorite lens 🙂.
The research:
A team of researchers performed a qualitative analysis on 487 software engineers, QA engineers, and program managers. Researchers collected free-answer responses and categorized them across themes to form a view of benefits, challenges, and attributes of pair programming.
The key takeaways from the paper include:
64.5% of respondents agreed that there are fewer bugs in the code because of pair programming.
Only about 40% of respondents said pair programming was working for their larger group, which researchers believe may signal the challenges of getting org-wide buy-in for pair programming.
Engineers did not feel strongly that pair programming takes more time to do than if the same work had been done alone.
Respondents answered that the top benefits were fewer bugs, spreads code understanding, high quality code, and learning from a partner. When asked about the biggest challenges, respondents said cost efficiency, scheduling, and personality clash in programmers.
The application:
This paper offers a glimpse of why and when a team should consider pair programming. Pair programming offers benefits in a number of cases:
For knowledge transfer (of domain knowledge or best practices): developers mentioned in multiple ways that pair programming can improve code quality and spread code understanding. This is especially useful for new engineers looking to build context, as well as for ongoing learning and development of early-to-mid career engineers.
To increase code quality: in companies where bugs are frequently introduced into the system, pair programming can be a useful technique for teammates to catch bugs earlier in the software development lifecycle. In many cases, the benefits of reducing production bugs offsets the cost of having two developers working on the same task.
Another benefit not directly mentioned in this research paper (but highlighted in the Thoughtspot analysis) is diversity. When diverse perspectives come together to build software, the outcomes are shown to be higher quality. Developers in the study call out the friction of working together with different personalities, but it is perhaps because of that friction that teams also notice better software outcomes. Creating a formal process for developers of different backgrounds to come together is a great way to experience the many benefits of having a diverse team.
Though there are many benefits, pair programming still needs to be introduced and reinforced into the culture of the team, and might not always be the best fit. Use this analysis to decide if it is right for your team, and remember that great processes take time to do well.
Wishing you all a wonderful (and spooky 👻) week - and happy Research Monday!
—
Lizzie
From the Quotient team