Pairing Hell

by Jeff Langr

August 23, 2016

pair hell

Image courtesy Chris Martin; altered from original. License.

“Pairing is hell. Okay, it’s also fun. But it’s also hell.” —Alex Harms, on pair programming.

Over fifteen years of pairing, and I too am similarly ambivalent about it. Don’t think I’m making a case for not pairing, however. I’ve written numerous times in support of pairing:

At least 16 more blog entries on this site discuss pairing, as do many at the Agile in a Flash blog.

So “hell,” really? Seems strong. Let me explain what I find to be a few serious problems with pairing cultures that can make it hell.

Overuse

As an introvert, I have a limit on the number of hours I can interact with people before I need to recharge (i.e. on my own). I regularly stretch this amount, which is ok. It doesn’t mean I’m not enjoying the interaction–particularly if it’s going well. It is heavily draining, however, which demands more recharging.

Pair programming was never meant to be the only thing you do all day. And yet I’ve done regular stints of 9-10 hour pairing days (at HEB in San Antonio for 7 months), or 7-8 hour days (remote at Outpace for the past few years). Trust me, those aren’t 100% fun hours for an introvert, no matter how well it’s going.

Sensible pairing shops set a limit on pairing. Six hours is plenty: three hours in the morning, three in the afternoon, a break in each. One shop I’ve helped mandates such a schedule to positive effect–no one feels pressured to stretch beyond reasonable amounts.

Pair-holes

Some people either never learned to play well with others or are incapable of it (i.e. it’s not their fault). Still, I believe most individuals are capable of learning how to interact effectively as a pair.

Having said that… there are definitely a (very small) number of pair-holes: people who should just not pair. Ever. Again. And I hope to never have to pair with these folks again. Fortunately for them and me, plenty of shops don’t mandate pairing, and shops that pair usually have other non-pairing things to do.

What makes a pair-hole? Mostly it’s someone who’s “always right,” or worse, someone who wants to argue (and not code) just for the sake of arguing. A keyboard dominator can sometimes be a pair-hole.

Many bad pair habits (inattentiveness, timidness, loud, etc.) can be corrected or overcome. A pair-hole is someone who doesn’t care enough to do so.

I’m not talking about people who want to think through problems on their own instead of with a pair. I think just about everyone feels that way some of the time, including me. I find that exploring things on my own is necessary as a regular thing. I find time regularly to do so–that’s one reason I seek slightly less than a full day’s pairing.

Poor Practice

Other than pairing too long, I’m mostly talking about pair marriages. We promote pair switching to increase coverage on everything. A pair can go down a rathole, just like a solo dev can. I suggest all shops incorporate a rule that says “at least 3 sets of eyes review every story,” whether through pairing or some other mechanism.

That’s the practical concern regarding pair marriage. The painful part: Being stuck with the same person day after day–or even all day long–can be a big pairing turn-off, like long walks down the beach can be (because you know you have to walk back). Switching at lunchtime can work well.

Pairing is a Tool

Pairing can be a highly entertaining, effective tool. For me, it’s often joyful. But it can at times be painful. The more you understand the extreme feelings and concerns people have with respect to pairing, the more you’ll learn how and when to effectively employ the tool.

If you’re not actively coaching your pairing and not continually adjusting your pairing practice (perhaps as a result of retrospectives), chances are good that you have the above dysfunctions.

Share your comment

Jeff Langr

About the Author

Jeff Langr has been building software for 40 years and writing about it heavily for 20. You can find out more about Jeff, learn from the many helpful articles and books he's written, or read one of his 1000+ combined blog (including Agile in a Flash) and public posts.