The perils of pair programming

The Agile Iconoclast goes solo

The Power of One Brief: Top reasons to choose HP BladeSystem

head shot of Matt Stephens smilingColumn 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.

Seven Steps to Software Security

More from The Register

next story
Secure microkernel that uses maths to be 'bug free' goes open source
Hacker-repelling, drone-protecting code will soon be yours to tweak as you see fit
KDE releases ice-cream coloured Plasma 5 just in time for summer
Melty but refreshing - popular rival to Mint's Cinnamon's still a work in progress
NO MORE ALL CAPS and other pleasures of Visual Studio 14
Unpicking a packed preview that breaks down ASP.NET
Cheer up, Nokia fans. It can start making mobes again in 18 months
The real winner of the Nokia sale is *drumroll* ... Nokia
Put down that Oracle database patch: It could cost $23,000 per CPU
On-by-default INMEMORY tech a boon for developers ... as long as they can afford it
Another day, another Firefox: Version 31 is upon us ALREADY
Web devs, Mozilla really wants you to like this one
Google shows off new Chrome OS look
Athena springs full-grown from Chromium project's head
prev story


Implementing global e-invoicing with guaranteed legal certainty
Explaining the role local tax compliance plays in successful supply chain management and e-business and how leading global brands are addressing this.
Consolidation: The Foundation for IT Business Transformation
In this whitepaper learn how effective consolidation of IT and business resources can enable multiple, meaningful business benefits.
Application security programs and practises
Follow a few strategies and your organization can gain the full benefits of open source and the cloud without compromising the security of your applications.
How modern custom applications can spur business growth
Learn how to create, deploy and manage custom applications without consuming or expanding the need for scarce, expensive IT resources.
Securing Web Applications Made Simple and Scalable
Learn how automated security testing can provide a simple and scalable way to protect your web applications.