Pair programming has been a topic of discussion, research, and adoption since the concept gained traction in the late ’90s. However, the idea still evokes mixed feelings from joy and energy, to anxiety and even anger among both engineers and managers alike.

It has become the Marmite of the software development world!

The concept is simple but powerful: “Two heads are better than one.”, and in the lean sense this embraces the “Build Quality In” principle. I’m going to dive into the pros and cons of pair programming, explore why it sometimes gets a bad reputation, and differentiate between effective pair programming and its counterproductive anti-patterns.

Pros of Pair Programming

Improved Code Quality

The biggest benefit of pair programming if executed well, is the improvement in code quality. The instant code review mechanism often catches errors on the fly, leading to more robust code. Because both parties actively engage in the process, the likelihood of overlooking mistakes decreases significantly. This can also reduce the need for pull requests as the code has already been reviewed and checked by the pair, and some teams are comfortable to skip that step once they have gained confidence in their process.

Accelerated Learning

Pair programming can be a fantastic way to share knowledge and skills. Both team members can learn from each other, whether it’s domain knowledge, programming techniques, or tips and tricks with the tools being used. As a side, you also get to know your team mates better and this brings an improved sense of belonging which can have other beneficial psychological benefits.

Enhanced Problem-Solving

Two brains can approach a problem from different angles, thereby coming up with more innovative solutions as each party brings their unique experiences, successes and failures and knowledge to bear. This is especially beneficial for tackling complex or unfamiliar problems where the expertise of both parties can prove invaluable.

Reduced Isolation

Programming is often considered a solitary activity, which can lead to a sense of isolation or burnout. Pair programming mitigates this by adding a social aspect to coding, and since Covid and the move to remote working this can bring additional benefits to our mental health.

Shared Ownership

When two people work on a piece of code, ownership becomes collective rather than individual. This approach can boost team morale and create a more cohesive codebase. The more a codebase starts to read like it has been written by one person, the consistency makes it easier to maintain and find your way around helping to speed up the onboarding of new team members.

Cons of Pair Programming

Decreased Velocity

Although pair programming may produce higher-quality code, it often does so at the expense of speed. Some tasks, particularly those that are well-defined and straightforward, might be executed faster when tackled individually.

Social Exhaustion

Not everyone is comfortable in constant close collaboration. The social aspect of pair programming, which some find invigorating, can be mentally exhausting for others. Having agreements on how long sessions should last is a great thing to put into a team charter, or even just an agreement between the pair. It’s supposed to be energised and rewarding, not a marathon challenge.

Skill Mismatch

If there is a significant difference in skill levels between the two engineers, it can lead to frustration. The less experienced engineer may feel overwhelmed, while the more skilled may feel held back. Without understanding and acknowledging the difference, this can cause further problems if any of the pair suffer from imposter syndrome.

Overemphasis on Consensus

There’s a danger of spending too much time in discussion, striving for a consensus that leads to design by committee and diluted responsibility. Techniques such as “disagree and commit” or better still, a “three amigos” before starting to cut code, can prove valuable. It’s better to make a decision and proceed than to face paralysis.

Why Pair Programming Gets a Bad Rap

Pair programming isn’t universally beloved, and there are some reasons for this negative perception:

Misapplication

Pair programming is often implemented without considering the type of task, the compatibility of the pair, or even the working environment. This can lead to unsatisfactory results, feeding a negative view of the practice. One technique tried with several of my teams has been to agree the level at which pairing is appropriate, for example, a team chose that any story less than 3 story points didn’t need a pair as it should be simple enough, but stories of 3 or more points, it should be the default unless they discover they have over-estimated later. This allows teams to self regulate the practice without it being used for all tasks, and it balances quality with throughput.

Resistance to Change

People have their working styles, and the idea of sharing your screen and constantly interacting with someone else can be intimidating, some have even stated they feel like they are having their capabilities evaluated (we will cover anti-patterns later in the series). Therefore, the initial resistance often stems from the fear of change. Try to minimise this by walking through the benefits to the individual, and again, let the team decide what level of complexity merits pairing. If coaching somebody on pairing and they are new to it, be happy to share where you have made mistakes and show vulnerability, this softens the mood and can make the experience more relaxed.

Poor Execution

Sometimes the failure is not of the method but of the execution. Misunderstanding the principles of effective pair programming can lead to an experience that turns people off from the idea entirely. Pairing comes with many anti-patterns, just like most agile practices, so familiarity with what good looks like is crucial to maintain adoption.

What Next?

I will continue the series with a breakdown of the behaviours needed to make pairing a highly effective technique, and a further breakdown of the anti-patterns that have given the techniques a bad press.

https://themoot.digital/pair-programming-effective-behaviours-and-anti-patterns/