by Rob Stearn

I've worked within teams that embraced pair programming and wanted to share some of what I learned, in the hope of inspiring you to try it.

"We can pair on it."

You've probably heard those words many times, but how often does it result in a good experience?  Why do we fail, as developers or managers, to embrace pair programming, despite our wish to do so?

First let's define what pairing is...

Definition

The general practice of pairing is simple:

  • TWO people
  • collaborating on ONE task.

In the domain of software development that simplicity gets more complex:

  • TWO people
  • collaborating on ONE task
  • sharing ONE screen & ONE set of input devices*
  • ONE Driver - inputting code
  • ONE Navigator - reviewing direction

There's no consideration of competency of the participants. Either can drive or navigate. Either can be teaching or learning.

* This might be one logical screen with 2 physical input devices if pairing with a remote colleague.

To give a bit more life to that definition, consider the word collaboration. Here's a definition:

Collaborate

kəˈlabəreɪt - verb

work jointly on an activity or project.

synonyms:    *cooperate,  join (up),  join forces, team up, get together, come together, band together, work together, work jointly, participate, unite, combine, merge, link, ally, associate, amalgamate, integrate, form an alliance, pool resources, club together*

Of the synonyms, 'form an alliance' captures best the spirit of pair programming. You need to form an alliance based on trust, respect and constant communication.

2++?

What about trios or quads? Does adding participants add value? Rarely.

There's a cognitive load to ensure you're both discussing the same mental model that you intend to codify. Another person adds exponentially to the load.

Effectively when you have more than 2 people you've formed a committee. I like this quote, purporting to express ancient Chinese wisdom on committees:

"A committee is an animal with four back legs"
John Le Carre from Tinker, Tailor, Soldier, Spy

In fact there is an excellent practice for collaborative coding with more than 2 people; Mob Programming. I won't go into detail on it here, other than to say that much of why pairing works applies to Mob coding too.

Why do we need it?

There's three outcomes to strive for with pairing:

  • Better code
  • Better people
  • Better process

Better code

While code itself is logical, the people who write the code are not. We all have bad days or moments of inattention or distraction and we can't help but build some of ourselves into our code. We introduce bugs because we confirm our own unconscious bias' and lack the ability to be truly objective about our creative output.

"The human eye has an almost infinite capacity for not seeing what it does not want to see ... Programmers, if left to their own devices, will ignore the most glaring errors ... that anyone else can see in an instant" [^1]

Pair Programming, by contrast has a reputation for producing code with six times less bugs than that produced by a single developer.

Also, the readability and documentation of code increases when the very process of generating it encourages explanation and clarity of thought.

Better people

If you lead a team, you value their feelings about their work.

In a survey of developers [^2], it was found that 90% were more confident in themselves and their code and 95% were happier in general when pair programming was a significant part of their working practices.

Better process

There's a lesson to be learned from Lean Principles, especially elimination of waste.

In this context waste could be defined as:

  • Time spent waiting for code review
  • Duplicated effort
  • Subsequent reworking
  • Post-release defect resolution
  • Time spent down 'rabbit-holes'

Your pairing partner is the extra set of eyes on the code. The need for such long and conflict-inducing processes like Code Reviews is greatly reduced by pairing. You and your pair are each others rescuer should you start to dive down a well-intentioned but indulgent rabbit-hole.

In the spirit of fairness, it's not true that pairing improves every metric, it's typical for work to take around 25% longer to complete as a pair.

However, remembering the reduction in time for review, and lower defect density, it's worth it.

Why does it work?

Pair programming is effective because it takes mental work and shares it with someone else. This is a concept defined as the Theory of Distributed Cognition.

This theory was defined in the mid-90's by Edwin Hutchins and describes how cognitive processes can be spread between people and artifacts such as pen/paper or computers, or anything that can represent state.

Consider a fiendish long division sum. To do this in your head, you need to remember multiple values in order to carry remainders as you traverse.

To reduce the possibility of errors you use a pencil and paper to note the values at each step and combine these notations to make the final result. You've just distributed the cognition of the problem across your own mind and the paper.

To quote Hutchins:

​“Knowledge is commonly constructed through collaborative efforts toward shared objectives, or by dialogues and challenges brought about by differences in persons perspectives.” [^3]

This highlights another positive aspect of pair programming, instead of differences of opinion producing heat, when expressed within a collaborative situation they can produce light.

Resistance

I've thought a lot about why, even in the face of evidence, we don't take advantage of pair programming.

I believe there are two fundamental reasons.

1. Fear...

...of looking foolish

When we make a mistake on our own, we can correct it without anyone being the wiser. Letting another pair of eyes see our process reveals a lot about our knowledge and abilities. Be open to this, seek to learn something by it.

...of conflict

What if our pair fundamentally disagrees with us? What if they aren't open to reason? What if it ends in an argument? This fear is out of all proportion to the likelihood. Conflict commonly arises from opposition, pairing is two people side-by-side looking toward the same solution.

...that sharing credit means losing recognition

Many of us exist in a world of performance reviews, objectives and metrics. What if our contribution to success is lost because it was a collaborative effort and not a lone hero(-ine) struggling to slay the beast? This is a reasonable fear, and requires managers and developers alike to be clear on not allowing it to become a reality.

...of not being able to justify two heads to one task

As a manager of people, how do you justify a practice that, from the outside, looks like you'll take twice as long to do anything? More on this later.

And the second reason?

2. Pride...

...that you're the smartest person in the room

There's nothing wrong with having pride in your skill and abilities, so why hide your light under a bushel? If you've got faith in your skills let them be seen by others, let others learn. If you find that you're not as razor sharp as you thought, be humble, learn and improve.

...that you don't need help

Yes, you can do this on your own. No, you don't need help. But the focus isn't you, the focus is the quality of the software and the value it delivers. Set your ego aside and accept help.

Summary

In this post I've talked about the theory of pair programming, in the next post I'll discuss how to make it work.

Rob Stearn is an Engineering Manager for the Print Operations tribe at MOO.

Sources

[^1]: ​​G. M. Weinberg, The Psychology of Computer Programming Silver Anniversary Edition. New York: Dorset House Publishing, 1998.

[^2]: http://www.cs.utah.edu/%7Elwilliam/Papers/ieeeSoftware.PDF

[^3]: https://onlinelibrary.wiley.com/doi/abs/10.1207/s15516709cog1903_1