Sure, two people working on the same task. But the benefits of pair programming justify it.

I have been in two scenarios where pairing went absolutely amazingly.

The first is when one person in the pair is a lot more experienced and willing to teach. This is typically called the novice-expert pairing. There are some great benefits with this pairing.

The obvious benefit is that there is the sharing of context and distribution of knowledge within the team. Around a year ago, I was in a project in the telecommunications industry. On the first day, I started pairing with the other developers, so from day one I was contributing towards delivery of work. This is significant given that I was ramped up within a week when, according to the StackOverflow Insights 2018, 44.7 percent of respondents said they expect a co-worker to take one to three months to get up to speed. I got to learn the acronyms and domain concepts that the stakeholders (both the business and telecommunications technicians and others) used because these were present in the code, and my pair would explain them all to me. This in turn increased my confidence in the code I was writing on a new codebase and also increased developer satisfaction. Zero time was spent floundering around trying to work out what the existing (and somewhat legacy) codebase did.

I am not alone in thinking this. Ninety-five percent of developers in a survey stated that they were more confident in their solutions when they paired. This is in contrast to some other projects I have been on where no one is willing to, or willing to make time, to share context, which leads to a downward spiral in self-confidence.

Photo by NESA by Makers on Unsplash

For similar reasons, pairing also is great for upskilling each other —after all, everyone has something to offer! If you have an Android developer and an iOS developer in the same team, they have the potential to upskill each other during pairing. Then, either of them can work on Android or iOS. Let that sink in for a moment — a completely cross-functional team can be very powerful. I was a part of this pair for some time, and we were able to share deep insights for different platforms. She learned how to make Android apps easily testable, and I learned how the UI in iOS apps work. You can imagine in a case where you have non-cross-functional teams; you may end up in a case where dependencies on certain people to do the work arise (leading to waiting time).

Most importantly, the code is of higher quality and produces less defects. In a study from 2000, Cockburn and Williams showed that when two people pair programmed, as opposed to solo programmed, there were 15 percent fewer defects, and this difference was statistically significant.

This is important because defects are often not considered when we talk about how long it takes to get the job done. Indeed, while the standard Definition of Done in Agile software development is centred around how can a story get to production and be of production quality (the two things are not the same), this concept is often forgotten. We tend to focus on how quickly stories are moving from the “Doing” or “In Development” column to the next column.

Defects are one of the seven wastes in Lean, and it is hard to truly evaluate the economic cost of defects because there are a number of non-obvious tasks that go into fixing defects. For example, the person fixing the defect may not be the one who worked on the corresponding story, meaning there is extra effort and time needed to understand the code (in a non-pairing scenario). Context is lost. Another example of a hidden cost of defects is that the functionality needs to be retested. Regardless, defects are most definitely rework and will delay a team in delivering good quality software.