Reasons Pair Programming Produces Better Code

Posted by

Experienced pair programmers claim that the code they produce is better than what they would have written on their own. But how exactly is ‘better’ measured? Most research studies on the topic measure it by the number of defects produced. But this type of analysis is over-simplified since code can be evaluated on many aspects including security, extensibility, simplicity, and the list goes on.

There’s also an aspect of subjectivity when measuring what is ‘better’. What’s better for one developer isn’t for the next. In that sense, it’s almost impossible to genuinely evaluate which code is best.

There are certainly logical reasons why pairing would produce better code. For starters, pair that is open with each other will be able to pinpoint flaws in the code more easily than a regular code review since both developers are intimitely familiar with the implementation details. Code reviews are too often examined only at a cursory level, resulting in less meaningful comments for the developer who requested it.

Pair Programming is an exercise in Continuous Code Review. Every statement is evaluated as the pair work together. Obvious mistakes can be pointed out as they happen, resulting in immediate feedback. That feedback can be addressed while it’s still fresh in everyone’s mind.

Problem solving in pairs is easier too. We’ve all been stumped by a problem and needed a second pair of eyes to give us a new direction to explore. In many cases boucing ideas back and forth will generate a better solution than thinking about it indivually. There is a counterargument (and extensive research) that indicates that brainstorming is an activity best left to individuals. With this in mind, pairs may be better off thinking of  solutions individually and then agreeing on and coding the final solution.

But the question remains: given the same problem and quality goals, would a pair produce better code every single time? It’s near impossible to say for sure one way or the other. At the end of the day, a team should have some form of review process, but what shape it takes should be left up to them to decide.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s