Why Pair-Programming Works

Recently, I’ve given a short presentation about pair-programming and the stereotypes people show while pair-programming. As always when talking about pair-programming, there is a discussion how to sell it inside a team to peer developers or even worse to managers. Their killer argument is that two people in front of a single computer result in doubled effort needed to complete software.

Let my show you why this is wrong.

Less defects are introduced

Pair programming is a just-in-time code review. Four eyes see more potential traps and defects than a single pair of eyes.

Bugs get more costly the later they are found. There is no earlier point in time to find and avoid a bug than when writing the code.

Less detours

Working as a pair results in discussion about the direction to take. Pairs won’t run blindly into the wrong direction quite as often as single developers do. And they don’t get lost as easily in technical details, too.

It is much easier to stay on track towards the goal and to stay focused on what is really needed.

Less interruptions

Pairs are interrupted less than individually working developers. Peer developers and managers are more reluctant to walk up to your table while you are pair-programming. Each averted interruption is worth at least 15 minutes of time – the time our brain needs to switch context back and forth completely.

Less distractions

When you are pair-programming, you never check your email or surf the web. The two developers keep each other safe from all the distractions that occur constantly.

Know-how transfer

Pair programming not only results in code. Pair programming is a constant know-how transfer. The pair shares know-how that would take a lot of dedicated learning time otherwise: design skills, team rules, coding guidelines, shared understanding what code should look and behave like and much more.

More motivation

Especially when doing a painful task like for example bug fixing, pair-programming helps a lot to keep up motivation. The two developers help each other to get over all the demotivating things that happen while coding: an idea does not work out, the IDE crashes, updating the source code leads to an ugly merge conflict.

Motivation is the major key to high-performing teams. A highly motivated team is at least 10 times faster than a demotivated team when including all effort needed to deliver defect-free software.

Shared style

A team practicing pair programming regularly develops a shared coding style. A shared coding style results in easier to understand code because everyone is used to a single style. For every line of code a developer writes, 10 lines of code are read. Therefore readability and understandability are highly important for a high-performing team.

Collective code ownership

When switching pairs often, every developer gets at least a glimpse of every part of the software built. Thus reducing risks of bottlenecks when developers leave the team, go on vacation or are simply out-of-office for the day. Bottlenecks are one of the worst performance killers out there. They result in context-switching, badly taken decisions, demotivation are complete stalls.

All these benefits outweigh by far the typing speed of two individual coders.

Note: as explained in my earlier posts about pair-programming, pair-programming has to be learned. In order for the positive effects of pair-programming to show, it has to be executed correctly.