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? ®

Other stories you might like

  • Experts: AI should be recognized as inventors in patent law
    Plus: Police release deepfake of murdered teen in cold case, and more

    In-brief Governments around the world should pass intellectual property laws that grant rights to AI systems, two academics at the University of New South Wales in Australia argued.

    Alexandra George, and Toby Walsh, professors of law and AI, respectively, believe failing to recognize machines as inventors could have long-lasting impacts on economies and societies. 

    "If courts and governments decide that AI-made inventions cannot be patented, the implications could be huge," they wrote in a comment article published in Nature. "Funders and businesses would be less incentivized to pursue useful research using AI inventors when a return on their investment could be limited. Society could miss out on the development of worthwhile and life-saving inventions."

    Continue reading
  • Declassified and released: More secret files on US govt's emergency doomsday powers
    Nuke incoming? Quick break out the plans for rationing, censorship, property seizures, and more

    More papers describing the orders and messages the US President can issue in the event of apocalyptic crises, such as a devastating nuclear attack, have been declassified and released for all to see.

    These government files are part of a larger collection of records that discuss the nature, reach, and use of secret Presidential Emergency Action Documents: these are executive orders, announcements, and statements to Congress that are all ready to sign and send out as soon as a doomsday scenario occurs. PEADs are supposed to give America's commander-in-chief immediate extraordinary powers to overcome extraordinary events.

    PEADs have never been declassified or revealed before. They remain hush-hush, and their exact details are not publicly known.

    Continue reading
  • Stolen university credentials up for sale by Russian crooks, FBI warns
    Forget dark-web souks, thousands of these are already being traded on public bazaars

    Russian crooks are selling network credentials and virtual private network access for a "multitude" of US universities and colleges on criminal marketplaces, according to the FBI.

    According to a warning issued on Thursday, these stolen credentials sell for thousands of dollars on both dark web and public internet forums, and could lead to subsequent cyberattacks against individual employees or the schools themselves.

    "The exposure of usernames and passwords can lead to brute force credential stuffing computer network attacks, whereby attackers attempt logins across various internet sites or exploit them for subsequent cyber attacks as criminal actors take advantage of users recycling the same credentials across multiple accounts, internet sites, and services," the Feds' alert [PDF] said.

    Continue reading

Biting the hand that feeds IT © 1998–2022