The perils of pair programming
The Agile Iconoclast goes solo
Column The streets of London are busy, especially at lunchtime. Strolling along dodging the slow-moving pedestrians occasionally makes me wonder: how do these people ever get anywhere? And how do they cope with the glacial slowness of taking all day just to reach the far street corner, without their heads exploding from the anticipation?
Probably the answer is that they don’t realise they’re moving especially slowly. They're as contented as a squirrel stuck inside a popcorn machine. Of course, some people want to walk faster: or they have an in-built, deep-down need to walk faster: they have their heads up and can see the street corner. They know exactly where they want to get to, and they've plotted a straight line to get there. They could get there in an instant if they're unhindered. But there's a logjam of mobile chicanes impeding their progress, forcing the faster walkers to either slow down and match the prevailing snail pace, or initiate some strange meandering manoeuvres to try and work around the slower ones.
So, in a tangential sort of way, this brings us to pair programming. If you pair a highly productive, expert programmer with a slower programmer, the results can be just as negative as the meandering street circus that I experience nearly every lunchtime (now there's some insight into my psyche that I probably should have kept to myself!). So anyway, the arrangement isn't merely frustrating for the more productive programmer: it's slowing him/her down, which in turn is slowing the project down, because s/he isn't getting as much done.
Of course, it isn't the slower programmer's fault. He may be a junior coder, paired up with a senior developer for an hour or two each day in the hope that some of the senior's lifetime-accumulated wisdom and eruditeness may rub off on the little tyke. The senior developer might even enjoy being the mentor, and there's much to be said for a deliberate set-up where a developer is mentoring the junior coders. That is, as long as the senior developer can return to his own solitary programming world for sufficient amounts of time to make up the shortfall in productivity. Swings, roundabouts and all that.
In their book Pair Programming Illuminated, Laurie Williams and Robert Kessler describe the different grades of programmer, and the effects of pairing them together: novice, average/intermediate, and advanced. Incidentally, the grading is based loosely on the programmer's level of experience, though the quality of a programmer's code and their level of productivity isn't necessarily a product of the number of years they've been chained to their keyboards: a natural-born coder may produce markedly better designed code before heading off to school, than a senior cube-dweller who mostly spends his day looking forward to the next pay-cheque.
(I explore these pairing (mis)matches further, and the effect of forcing pair programming upon reluctant employees, in Extreme Programming Refactored. I also explore the implications that pair programming has on code ownership and responsibility).
Yes they are, no they're not
It's indisputable that some pairings work better than others. As you might expect, average-average pairings work the best because (in theory) the pair can just get on and write code without tripping over each other's shortcomings. Other combinations, particularly novice-novice and novice-advanced, can be as problematic as traversing Oxford Street during the New Year sales.
As you also might expect, agile aficionados have an answer: pairs must rotate partners frequently, so that ill-matched/inefficient pairs aren't sat together for too long. But this reminds me of that episode of Father Ted (and every other sitcom featuring a “straight guy” and his stooge) where Father Dougal is looking at the flashing Christmas tree and saying: "The lights are working! Oh wait, no they're not. Yes they are, no they’re not...”
But crucially, not everyone likes pair programming. Not everyone is naturally extroverted or a social butterfly that will wither away if he doesn't get to chatter to his colleagues for eight hours a day.
"So what?" an imaginary team leader with a Hitler complex might say (as if such team leaders really exist). "Those introverted types won't get to work on my project, then. Pair programming is the future, and those solitary, intellectual dinosaurs don't belong in the New World Order."
But it seems a tad rum to fire a perfectly good developer just because he doesn't want to squeeze in next to a BO-radiating, garlic-breathed intern for the whole summer. And, preferring to have some peace and quiet to program does not a bad programmer make: in fact, I'll stick my neck out and say that this preference is a good indicator of a damn fine programmer.
So if many good programmers are not naturally inclined to pair program, how do you find the staff (short of lurking around Extreme Tuesday get-togethers and abducting the attendees)? Recruiting is an important issue often overlooked when discussing the pros and cons of pair programming. I spoke to someone at a recruitment agency who lamented the near-impossibility of finding job candidates who were willing to pair program for a living. And almost without exception, any programmer to whom I mention pair programming shudders at the very concept.
This is not to put down occasional, non-mandatory pair programming, because it certainly has its uses when not overdone. And some companies do make pair programming work (or so they say). However, the practice certainly requires strong, constantly attentive management. And making it mandatory 100% of the time, and expecting a mixed-ability team to sort out their differences in abilities and still be highly productive, is just asking for trouble.
Matt Stephens is the author of: Extreme Programming Refactored, which objectively throws XP into a pit of rabid hamsters; Agile Development with ICONIX Process; and Use Case Driven Object Modelling with UML.
Sponsored: Benefits from the lessons learned in HPC