Are Two Brains Better than One? The Pros and Cons of Pair Programming
Pair programming refers to a software development technique where two programmers work together to solve the same problem. Traditionally, pair programming meant that the two programmers would share the same physical workstation with one keyboard between the two of them. The person with the keyboard would serve as the “driver” and write the code, while the “navigator” would check the code for bugs and offer advice. However, the rise of work from home arrangements and the COVID-19 pandemic means that developers are often working from different locations and sharing an office may not be a realistic option. Fortunately, pair programming can also be done remotely with tools such as Discord, Zoom and VS Code Live Share. Rather than passing around a keyboard, the participants agree on roles ahead of time and switch at predetermined intervals.
Proponents of pair programming argue that pair programming improves the quality of code, provides new learning opportunities and increases programmer satisfaction. A 1999 study by the University of Utah compared two groups of software engineering students, the first group worked on their projects solo, while the other worked in pairs. Although the pairs spent 15 percent longer on the project than the individuals, their code had 15 percent fewer errors. The pairs were also able to implement the same functionality in fewer lines of code. (Cockburn & Williams, 2001).
By sharing ideas and pooling their knowledge together, the students were able to solve more difficult challenges. Collaboration is also useful for keeping people on-task, the accountability associated with pair programming led to the student’s working with more focus. While pair programming the students spent less time surfing the web, talking on the telephone and checking email (Williams, et al. 2000). It is also worth noting that the time gap decreased between the individuals and the pairs decreased on subsequent projects. The researchers speculate that the time gap on the first assignment is partly due an initial adjustment period (Cockburn & Williams, 2001).
The study also found that the students programming in pairs experienced an increased level of satisfaction in their work. Over 90 percent of students reported that they enjoyed the project more due to pair programming (Cockburn & Williams, 2000).
However, many studies on pair programming conducted in academic settings so it is difficult to draw definite conclusions about their applicability to the workplace.
While pair programming has certain benefits, it may not be right in certain situations. For example, personality conflicts can be a major obstacle to productive pair programming. These conflicts can arise when one partner has an excess ego and is unwilling to listen or consider different approaches to solve the problem. On the flip side, partners who are not assertive enough may be hesitant to give their opinions and contribute little to the project (Williams, et al. 2000). Pair programming tends to work best when both developers are at a similar skill level. While senior/junior pairings can be useful for mentorship, they are not always productive. In order for these pairings to be successful the junior must be given ample time as the driver. When juniors are placed in the navigator role, they can often become passive spectators (Varga, 2017). Pair programming can also be more draining than solo programming, particularly for introverts. While some thrive off constant social interaction, others find it tiring and time to work alone (Waith Mair, 2019). Pair programming tends to push developers to stay on task. While this is generally seen as an argument in favour of pair programming, many developers see free exploration and experimentation as an essential part of their growth and learning (Waith-Mair, 2019). Pair programming can have many benefits, but it is not a silver bullet. The decision to pair program or solo program must be made with the individual developers in mind.
During my time as a web development student at Lighthouse Labs, I had the chance to experience programming in a collaborative environment. The first time I heard about an upcoming pair programming assignment, I was a bit nervous about the idea. I was only a few weeks into my coding journey at the time and felt hesitant to code with someone else watching. What if my partner was significantly more advanced and felt that the pairing was a waste of time? What if I wasn’t able to contribute? It turns out these fears were mostly unfounded. Were there times that I was paired up with someone significantly more advanced? Absolutely. However, they always enjoyed sharing their knowledge since teaching someone else is one of the best ways to deepen your own understanding. I found out about new methods and tricks from that first pair programming session. Did I understand everything the more advanced programmer was doing at the time? Nope, but afterwards I knew the right questions to google. Likewise, when I was paired with someone less experience I did not feel like the exercise was a waste of time. You feel like you truly understand your code when you can explain what you’re doing to someone else. Anytime I was unable to explain my reasoning, it was often a sign of problems with my code. Explaining your code to someone else forces you to question your logic and approach to solving the problem. Additionally, many bugs are caused by small errors like typos and incorrect capitalization. These errors can be caught by anyone regardless of skill level, making an extra set of eyes useful. I started programming in late 2020, so my experience with pair programming only of the remote variety. One issue with remote pair programming is confusion about who is the driver at any given time. During one pair programming session, both of us started typing in different parts of the code editor, aka driving. Without a physical keyboard to pass around, it can be tempting to start editing the code instead of waiting for the driver to consider and implement your suggestion. When I realized that I was driving when I was supposed to navigating, I quickly apologized to my partner and it was not an issue. I find that any issue in pair programming can be fixed as long as you are willing to admit your mistakes and communicate. Clearly defined roles and clear communication are keys to making a pair programming partnership successful.
Sources
Cockburn, A & Williams, L. 2001. “The Costs and Benefits of Pair Programming” Extreme Programming Examined, pp 223–243.
Varga, Martin T. 2017 “Pair Programming is hard. Codeburst. https://codeburst.io/pair-programming-is-hard-a5da3449b67
Waith-Mair, 2019. Justin T. “Pair Programming: The Good, The Bad and, The Ugly”. Medium. https://medium.com/the-non-traditional-developer/pair-programming-the-good-the-bad-and-the-ugly-5fc3f9c3663c
Williams et al. 2000, “Strengthening the Case for Pair Programming” IEEE Software, pp. 19–25
