Since the dawn of XP, I've read about the benefits of Pair Programming. Evangelists have told us that it will improve code quality, help knowledge dissemination, and even boost productivity, all while cultivating deep, soulful bonds between developers (see: spooning).

Those who reject pair programming are assumed to be cowboys, slackers, or social recluses. Well, I'm none of these (at least I don't think), but yet I still hate the idea of Pair Programming. For what it's worth, here's why...

We are no longer a culture that respects silence. The extroverts have won. Everything must be done collaboratively. Everyone must be available to everyone, all the time. There should be no more personal space, and no ownership of work. Basically, we believe that two heads are always better than one.

And yet it should be obvious to us that this is not always the case. Just in the world of programming, some great works of innovation and craftsmanship have sprung not from a team or a pair, but from the efforts of one person. I think about Ant, a huge leap forward for the Java community at the time, developed by one guy on a flight from Europe to the US (1). Or a tad more current, consider Notch of Minecraft, Marco Arment of Instapaper, or Gabriel Weinberg of DuckDuckGo: all solo achievements (2). In fact, one of the most influential programmers (if not people) in the world, Steve Wozniak, famously advocates:

"Work alone. Not on a committee. Not on a team."

Going further, some of the greatest thinkers in science and art are of the heads-down (i.e. introvert) variety - think Darwin, Einstein, Newton, or heck, even Dr. Seuss (3). Even John Steinbeck chips in here:

Nothing was ever created by two men. There are no good collaborations, whether in music, in art, in poetry, in mathematics, in philosophy. Once the miracle of creation has taken place, the group can build and extend it, but the group never invents anything. The preciousness lies in the lonely mind of a man. (4)

Ok, I'm waxing philosophic here, but back to our own little corner of the world, software development, why would we believe, as some argue, that hyper-collaboration (e.g. pair programming) is a precondition to quality or productivity when we can readily think of so many counterfactuals? Why, for some, is Pair Programming a "must do", all the time?

I believe it's just a reflection of one's own personal psychology. Simply: some people enjoy this style of work, and so they prescribe it, vociferously, for everyone.

The truth is, however, that one third of us are introverts (and probably more for programmers!). In general, we not only prefer but thrive when working in solitude. It's not that we don't like people, it's that our brains are wired to be more disrupted by stimulation (and, for good or bad, this includes pairing). For us, doing quality work is about getting and staying in "the zone". When we do, we're highly productive. When we don't, we flail.

Demarco and Lister, in their famous Coding War Games experiment, demonstrated just this - the best predictor of quality for programmers, they found, was not years of experience or salary but rather how quiet their office environment was.

This used to be a respected insight. In fact, #8 on the Joel on Software Test of good places to work is "Do programmers have quiet working conditions?" Sadly, however, the culture of hyper-collaboration has rolled over our better sensibilities, and to be perfectly honest, I think it kind of sucks.

Pair Programming, an extension of this "everything-together" culture, has permeated our thinking to the extent that many think that one person working in isolation is not just ineffective, but boring to boot. For me, it's the opposite. My best work is done in solitude, and the state of flow is what I enjoy most about being a programmer. It's not about being a "cowboy", or thinking I'm above mistakes. I'm a huge advocate of rigorous code reviews, and I benefit daily from the insights of others. It's just that the hyper-collaborative state of pair programming doesn't make me a better (or happier) programmer. Please take my word for it.

When people describe pair programming as a practice that they benefit from, cool, I get that. But when they take the next leap and advocate (or mandate) the practice for me, because they "know" I'll benefit from it (and have "data" to prove it!), slow down. The methods by which people produce quality work are as varied as we are. Consider some great achievements in the world (or just on your project!) and this should be obvious. To claim that this extrovert's ideal of pair programming is a "best practice" for all is foolish, I don't care what the agile dogmatists say.

References

Recent Posts