The perils of pair programming

The Agile Iconoclast goes solo

Reducing security risks from open source software

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.

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

More from The Register

next story
NO MORE ALL CAPS and other pleasures of Visual Studio 14
Unpicking a packed preview that breaks down ASP.NET
Captain Kirk sets phaser to SLAUGHTER after trying new Facebook app
William Shatner less-than-impressed by Zuck's celebrity-only app
Apple fanbois SCREAM as update BRICKS their Macbook Airs
Ragegasm spills over as firmware upgrade kills machines
Cheer up, Nokia fans. It can start making mobes again in 18 months
The real winner of the Nokia sale is *drumroll* ... Nokia
Mozilla fixes CRITICAL security holes in Firefox, urges v31 upgrade
Misc memory hazards 'could be exploited' - and guess what, one's a Javascript vuln
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
Google shows off new Chrome OS look
Athena springs full-grown from Chromium project's head
Apple: We'll unleash OS X Yosemite beta on the MASSES on 24 July
Starting today, regular fanbois will be guinea pigs, it tells Reg
prev story


Top three mobile application threats
Prevent sensitive data leakage over insecure channels or stolen mobile devices.
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.
Boost IT visibility and business value
How building a great service catalog relieves pressure points and demonstrates the value of IT service management.
Designing a Defense for Mobile Applications
Learn about the various considerations for defending mobile applications - from the application architecture itself to the myriad testing technologies.
Build a business case: developing custom apps
Learn how to maximize the value of custom applications by accelerating and simplifying their development.