Pair Programming Is No Panacea

I'm working on a project where we have two parallel efforts underway to investigate alternative solutions to a problem. At first this bothered me, I was worried that people would drift apart. That we'd reach an impasse and wind up throwing away a lot of work. But, surprisingly, it's led to rather novel benefits. 

In having separate efforts, we're coming up with different ways to solve the challenges we face. And, we're learning more than we would if we were working together.

There's tremendous value in isolating efforts so as not to cross-pollute thinking.

Recently, we started to sync up and that's been bothering me because I want to preserve the discrete streams of thought.

I've found that I'm managing a trade-off between divergent and convergent thinking. There are benefits in each and I'm working to maximize the natural divergence of sequestered endeavors.

It's easy to overlook the benefits of working alone when people sing the praises of teamwork. It's easy to fall onto the end of what is a spectrum. The spectrum from isolated work to collaborative work.

Usually we think of this as a dichotomy between teamwork and individual work. But it can also be isolated groups working independently versus one large team.

Why is this worth thinking about?

People that work together have a tendency to think together.

Groupthink can be good in situations where you want to build consensus. But it can also be disastrous if you want to tap into the intellectual diversity of a group of people.

Certainly, you can pull off divergent thinking in groups, but doing so is fighting gravity. It requires awareness and techniques employed by the group to tease out a broad perspective instead of a narrow perspective.

Contrast this with people working alone. The tendency is divergent thinking. Simply because individuals don't know what other people are doing so they can't be on the same page. The longer the isolation, the greater the divergence.

These tendencies explain why brainstorming--locking people in a room to devise creative solutions--is often counter-productive. The multitude of minds follow one train of thought, that of the group. 

Pairing

Our divergent project reminded me of the alarming danger in prescribing how people should work together. In the last five years I've come across many people that extol, and mandate, pair programming to develop software.

For some, pair programming has become an absolute truth.

Without question, I've heard people proclaim that they only develop software in pairs. That to do it any other way is negligent.

From these same people I've heard nothing but glowing reviews of the benefits and many of them can't enumerate a single drawback.

This gives me pause. I firmly believe there is no wrong way to do the right thing.

Alistair Cockburn and Laurie Williams authored a paper entitled "The Costs and Benefits of Pair Programming"¹. Never once do they list a condition whereby one should avoid pair programming.

Quite the opposite, the article seems to imply that pairing should be mandated. To be fair, the article doesn't explicitly come to this conclusion. But, what am I to surmise when the summary is a glowing list of benefits without a single mention of consequences?

Generally speaking, with pair programming, people proclaim the following benefits:

• Fewer defects
• Increased creativity
• Better design
• Team building
• Sharing of knowledge, including bus insurance
• Increased feedback and desensitization to receiving feedback

Let's talk about these benefits, because after all, what's the point if not for the benefits?

There's no doubt that people working together leads to sharing of knowledge, the ability to work better together, and to less defensiveness about feedback. But, let's not forget there are a myriad of other techniques to achieve the same ends.

Better design and creativity

Two heads are better than one. It's easy to fall into this specious trap.

In the aforementioned paper¹, which included a supposed scientific study, that then made claims of statistical significance:

the pairs not only completed their programs with superior quality, but they consistently implemented the same functionality as the individuals with fewer lines of code… We believe this is an indication that the pairs had better designs.

A compiler can take any chunk of human code and transform it into fewer lines of code. Same design, fewer lines of code. A quantitative analysis of the number of lines of code has no bearing on the quality of code.

There's no way to quantify design and creativity.

Design is largely a qualitative assessment. One that I wouldn't trust given the glowing recommendation coming from the study authors. We all have a propensity for confirmation bias.

For every argument that two people are better than one, I can provide counter examples that one person can be better than two. Or, two people working alone could be better than two people working together.

If you're going to have people working together, you should be aware of the ways in which this can lead to a decrease in creativity:

Groupthink

Instead of divergent thinking, thinking can easily converge along the lines of whatever first comes to mind within the group.

The same way that thinking converges when an individual works on something. The result is the same mindless intellectual stumbling.

Let's say you're working with a team of people that have been tasked with forging a trail to the top of a mountain. Let's assume this is new frontier, nobody has mapped a route to the top.

If at every critical juncture you act upon the first idea someone has, that's no different than an individual that acts on the first idea they have.

Fear

Individuals that fear rocking the boat won't speak up. And you can't just tell people it's OK to speak their mind. There are power dynamics at work that will always silence people.

You never know when someone feels their job might be on the line, someone that has a family to feed.

Shared Perspective

The longer people work together the greater the chance they share the same perspective. When a challenge arises, they'll often generate similar solutions simply because they're primed by the same biases. Creativity comes from people that can look at a problem from a different angle, not the same angle.

As the team forging a path gets further up the mountain, they'll share more and more in common. That means individual perspectives will converge simply because individuals draw from the same experiences.

If the team encountered a stream of water that's rather deep and persevered by finding a fallen tree to walk across, then when they encounter another stream, they'll search for another fallen tree. Perhaps neglecting to check the depth of the second stream that they could simply walk across.

Creativity is correlated with what's going on in the mind(s) of people working on a problem, not the number of people working on the problem.

Defect reduction

The study¹ reported 15% fewer defects from work done by pairs. The study had an astonishing 20 participants. The participants were not versed in programming prior to the class. It would be pseudo-scientific, at best, to generalize the results of this study.

Extrapolating these results to experienced professionals would be akin to saying that doctors shouldn't be allowed to perform operations alone because medical students learned better in pairs in a medical school study.

Let's just be honest that the discussion of defect reduction, as well as the entire discussion of pair programming efficacy, is anecdotal.

Defects, like creativity, aren't so easily quantified. The study used test cases as an indication of defects. In reality, defects are rarely anticipated by test cases.

Test cases are a measure of conformance to a specification. There are a whole host of defects that happen because of what's not in a specification. Often, what is miscommunicated.

Sure, there are wrong ways to implement a specification. Which is what this study measured. But there's no right way to build the wrong thing--when the specification is wrong. That's where the majority of defects come from, in my experience.

Last, implicit in a discussion of defects, is timely feedback about defect detection.

This seems to be what the study is hinting at. Feedback is one of the potential benefits I see in pairing. The ability to get feedback from someone else, quickly.

Feedback is why we intuitively, and spontaneously, pair with other people. Pairing is also known as asking for help and subsequently working together.

Pairing is extolled because of the immediacy of feedback.

There is value in immediate feedback. But that value is in the timely nature of feedback more than the immediacy. Simply put, if I tell you about a mistake you made a year ago, that's not very helpful.

Timely doesn't necessitate immediate. And, immediate feedback has potential consequences:

• A reviewer may not think before speaking. If the pair acts upon this feedback, the feedback is counter-productive. Isolation can be a good thing when reviewing someone's work. It gives a reviewer the chance to reflect on what they're feeling.
• A reviewer may regret what they said in the heat of the moment.
• Aside from simple mistakes, a reviewer that's engaged in the work is akin to a person reviewing their own work. Their feedback is primed, and limited, by the shared perspective.
• A person being reviewed might not know how to appropriately handle feedback. Even if they’re seemingly desensitized, if they can’t disambiguate helpful versus harmful feedback then they’re potentially in for an emotional rollercoaster.

Certainly if you believe that the value of feedback is only directly proportional to immediacy, then you would fall into the trap of advocating for paired work.

But, the value of feedback is also immensely tied to the divergence in thinking between the reviewer and the recipient of the review. In my experience, this is more important than timeliness.

I'm not going to learn much from people that think like I do, other than when I'm not thinking within my own box.

Valuable feedback comes from people that don't think like I do.

Demoralizing

Certainly, teamwork is a result of collaboration. 

But, if you mandate people work in pairs--and never alone--you run the risk of creating a culture that devalues individual contribution. Even if you only mandate pair programming for writing code and allow people to work independently on other aspects of software development, say ideation, you still run the risk of devaluing individuals.

When you mandate all coding be done in pairs, you're sending a message that individuals are incapable of writing worthwhile code. And that can have damaging consequences, most notably that individuals will begin to doubt their own capabilities. Which then becomes a self-fulfilling prophecy, perhaps in that individual's future work, or other areas of their life.

People can wind up becoming dependent on others for their confidence. And then when they no longer have that externalized confidence to rely upon, their world can come crashing down. Say when they move on to another job, or if for some reason you decide in the future that pair programming isn't the be-all and end-all of methodologies.

And, why is it that one person cannot write correct code, but, two people can?

Two people asleep at the wheel still results in an accident. An overly confident pair can be just as ineffectual as an overly confident individual.

Be situational

Mandating pair programming is as foolish as mandating solely individual work. Human beings intuitively know when it makes sense to work with someone else. Perhaps they don't use the tool of pairing as often as they should, but they nonetheless intrinsically know its value.

Because pairing is a question of efficacy, we should ask ourselves what we hope to gain. Then, we should identify alternatives before we blindly subscribe to the Church of Pairontology.

If you have problems with defects, pairing may help. But, keep in mind what you're really looking for is feedback. There are other viable approaches: testing, code reviews, static analysis, and customer feedback.

Also, when it comes to feedback, it's a false equivalence to compare individual work, without a code review, to pair programming. It would be better to compare pairing to code first, review second. That way you're considering two people in both approaches. And you're getting feedback in both situations.

Though, with that said, I'm not suggesting that an individual can never work alone.

If you have problems with teamwork and communication, pairing is certainly not the only way to approach this. Likewise, with sharing knowledge and bus insurance.

If you're writing code and creativity doesn't matter, there's no reason to pair. For example, when changing a report format. In this case you're really arguing the merits of a code review during or after, either can be efficacious. And if you don't need a code review, then pairing is definitely a waste of time.

If creativity matters, keep in mind that pairing can compromise creativity. Creativity has more to do with what people are thinking and feeling than the number of people. An individual on the fence, that can see multiple sides of an issue, will be more creative than two people that are in agreement.

You'll be far better off teaching people how to avoid creativity traps, than pretending that mandating pairing is sufficient to afford creativity. For example:

• Pairing people with low emotional intelligence is a sure bet to decrease creativity.
• It's easy to accidentally influence someone in a counter-productive way.
• Groupthink squelches differing opinions.
• Leveraging creativity involves knowing when to broaden perspectives and also when to narrow perspectives. 
• Identifying personal biases can help one see things from a new perspective.

If you feel that creativity is absolutely essential, then it does make sense to involve more people.

These people should all be well versed in the pitfalls of creativity. And when you seek to involve more people, it's healthy to have a discussion of how best to do it, for example:

• You could use pairs.
• You could have a team of three or more people.
• You could have one person write the code and another person review after.
• You could have two individuals work independently, and then consolidate their solutions.
• You could have two pairs work independently, and then consolidate their solutions.
• You could bring in an outside party in any of the above situations.

I'm sure you can imagine other possibilities.

They key is divergent thinking, there's no one right way to achieve that.

And when it comes to selecting a method, that should be up to the people doing the work. No methodology produces results if the people applying it don't know why they're applying it.

References

1. “The Costs and Benefits of Pair Programming”.

About the Author

As a consultant, Wes Higbee helps organizations produce rapid results by focusing on what matters.
His career has been a journey. He started out in software development helping organizations tackle business opportunities. In working closely with customers as a consultant, he realized there are many needs beyond the software itself that nobody was taking care of. Those are the needs he addresses today, whether or not technology is involved.
He authored the book Commitment To Value: How to make technical projects worthwhile. He’s authored 14 courses and counting with Pluralsight and O’Reilly. He writes extensively about business on his blog. And his written work includes articles featured on VeraSage, MSDN Magazine, and InfoQ.