Is pair programming for you?
By: Michael Xie
Tags: Pair Programming, Agile Methodology

Pair programming is a term that was popularized by Kent Beck in his book “Extreme Programming” in the late 1990s. It is a tool used to increase productivity and code quality in an agile development setting. In spite of its seeming benefits, its wide adoption has been a mixed bag. Here, I will break down what it is, when to use it, and how to effectively use it.

What is pair programming?

Roles in pair programming. Source: Böckeler and Siessegger (2020). On Pair Programming.

In a nutshell, pair programming involves two people solving a problem together on the same computer. Each person has two interchangeable roles — the driver and navigator. The driver will be the one writing the code, while the navigator reviews the code written, foresees future issues, and plans ahead.

Why should it be used?

Often the initial reaction to not use pair programming is its economics. Having two programmers writing half as much code seems like a waste of money. Another common reason to not pair program is that many programmers claim they are introverts and don’t want to interact with a partner constantly. These concerns were investigated in different studies.

In one study conducted by Cockburn and Williams (2000), they found that pair programming had a development cost of 15%, but provided improvement in code quality, enhancement in skill level, and better communication. Furthermore, participants showed statistically significant levels that the experience was more enjoyable as compared to solo programming. Furthermore, Satratzemi and others (2018) found that in distributed pair programming, students found pairing with someone with a similar experience level was most enjoyable. Similarly, Salleh, Mendes, and Grundy (2011) found through their literature review that students with similar experience level work more effectively in programming tasks, but had mixed results when looking at personality compatibility.

Benefits and Costs

Source: Böckeler and Siessegger (2020). On Pair Programming.

Pair programming brings many benefits to the individuals and the work they produce. First, each person brings along a different set of knowledge and perspective, especially with the addition of the two roles. This provides opportunities to share knowledge and create dialogues that help identify potential issues and formulate plausible solutions. As a result, the code is reviewed on an ongoing and real-time basis. The total number of bugs to resolve and time to resolve bugs decreases. Since the code is seen by both people, they are more confident to make changes. This collective ownership of the codebase makes each member more accountable and at the same time engaged and focused on one issue at a time. Despite higher development cost, pair programming helps develop a team dynamic, while improving code quality.

Source: Moore (2016). I’ve Pair Programmed for 30,000 Hours: Ask Me Anything!

With many good things, the benefits are best done in moderation, else there could be some consequences. First, pairing can be physically and mentally exhausting due to being very focused for a prolonged period of time. Second, collaboration requires constant communication and empathy. It can be hard and be affected by many factors like experience level, power dynamics, and personality type. Third, team flow can be disrupted by other priorities. Last, simple tasks can be complicated by pair programming.

When should pair programming be used?

As seen from above, pair programming has many benefits, but at the same time, it can carry many side effects.

Some scenarios to use pair programming include:

On-boarding a novice with a more experienced programmer to understand the codebase better

Applying Test-driven Development in a more interactive manner, where the driver would write a test, and the navigator will have to write the code to pass it. After the roles are reversed to write more tests and codes to pass them.

Completing complex tasks or unfamiliar tasks that could leverage the division of responsibilities and perspectives of the driver and navigator roles

How to be effective when pair programming?

Do’s

take regular breaks that suit the pair, like every 25 min for 5 min or 50 min for 10 min

switch roles after each break

allow yourself to be vulnerable and ask questions that you think might be “dumb” or don’t understand

give credit to your partner in code commits

Don’ts

be dictating what to do and micro-managing as compared to having a collaborative relationship with your partner³

be distracted like by looking at your cellphone³

be in a passive role when engaging new concepts³

Recommendations

Use pair programming when tackling a challenging problem, and switch to solo programming when solving simpler problems that you have seen before

Set aside time for yourself, and time to pair program

Switch partners when you become too comfortable with each other. This will add a new set of knowledge and experiences, and team dynamic

In a pairing setting with an expert and novice to a code base, be mindful that knowledge sharing would take longer. In the long run, the novice could share the workload and the expert could learn new ideas from the novice

References