This article is more than 1 year old
Pair programming – you'll never guess what happens next!
Oooo, oooo, that smell…
Of all the agile practices out there, “pair programming” is the one that elicits the most heckles, confusion, and head-scratching. The idea is that rather than having one person sitting at a screen, coding, you have two who program together. Those who practice it speak of it like most people do of their first time at Burning Man, while those who have never had the “experience” just can’t see what the big deal is.
While finding them are hard, over the years studies of pair programming have consistently shown that it’s an effective way to keep bugs out, write code faster, manage the risk of developer churn, and actually raise morale.
But – really? Looking at surveys, I’d estimate that somewhere south of 20 per cent of people do pair programming. If pair programming was so great, why do people find it so odious? I mean, who wants to work so close to someone that you can smell the effects of coding?
And as if it wasn’t enough to keep that foetidly in the developer cubes, it’s been wafting into the server room despite those cyclopean fans in there: operators are starting to pair as well.
Four eyes are half the productivity as two?
The theory behind pair programming is straightforward: programming is difficult and error prone. It’s much better to have a buddy helping along. In addition to actually coding together, it sometimes means having one developer write code and the other write tests right next to each other, in co-ordination. With two heads together, the thinking is that you write less bugs and get better test coverage.
Indeed pairs in studies over the past 20+ years have consistently written higher quality code and written it faster than solo coders. So, while it feels like there’s a “halving” of developers by pairing them up, as one of the original pair programming studies put it: “The defect removal savings should more than offset the development cost increase.”
Safer coder killing
If the pairs rotate frequently, the theory says you’ll get better diffusion of knowledge across the team: no one person builds up a fief of knowledge around, say, builds, or how the “Print Invoice” function works. This means there’s a lower “bus factor,” helping protect against team churn and brain-drain.
Large organisations I talk with - who’re all trying to figure out the footwork for that “digital transformation” dance - use rotating pairing as a way to spread new technical knowledge, but also change that oh so mysterious “culture” in their organisation.
People actually like it
Much like alcohol and black coffee, pairing tastes awful at first... until you start imbibing of it repeatedly. In most of the studies, and the feedback I hear from organisations doing it nowadays, pairing practitioners end up liking it after just a few weeks. At first, true, the usually solitary programmer has to, you know, talk to someone else. They even have to get used to be corrected by someone else – horrors of all horrors!
But, with a rigorous enough schedule that allows for breaks and bounds the programming time to normal 9-to-5 schedules, most people end up liking pairing after a while. It only takes a few pints to dedicate your life to it.
It’s hard to say why people like it more, but I suspect it has something to do with the fact that humans, fundamentally, like being social, so long as it feels safe. Also, most programmers and operations people take pride in their craft: they want to do good work (despite what those overflowing tickets queues are doing to them). If pair programming increased quality, there’s more to be proud of.
Managers of these programmers should also like the quality, speed, and predictability of pairing.
That predictability comes from an interesting side effect of how exhausting pair programming is. For one, it’s harder to goof off – er, “check email” – and attend meetings when you’re pair programming. As the man from downtown said: “Always Be Coding.”
And, on that kind of schedule, developers are straight up pudding-headed after seven or eight hours of pair programming. As one practitioner put it: “This makes pair programming intense, especially at the beginning. At the end of the first day, I couldn't go home. Before I could face humans again, I put my phone on airplane mode, ignored my usual online accounts, and went to the gym for two hours of self-imposed isolation.”
Developers can only pair so long. They have to stop, so you just close up shop at 5. No more playing Doom until 10pm and then coding – er, I mean “working late".
It can come off as sounding a bit like nanny-management, but pair programming seems to induce developers to actually do the work.
Yeah, but… no
While the research is sparse (and, really, when it’s “n=whatever students enrolled in my CS class” it’s a little fishy), from where I sit and what people keep telling me, pair programming works. Should you be doing it all the time, though?
I’ve heard practitioners say that you should at least do it for complex, difficult tasks. If it’s some routine coding or operations tasks, then pairing may not be the nitro-charge you’re expecting. Indeed, one of the studies suggests that pairing is the most beneficial for “challenging programming problems".
Put another way, if the task is “boring,” maybe it’s better to solo it. Still, I can’t help but think that it’ll be the boring tasks that end up biting you, especially when it comes to pair sysadmining. After all, how many systems have come down because of the boredom of DNS configurations? ®