Feeds

The perils of pair programming

The Agile Iconoclast goes solo

Choosing a cloud hosting partner with confidence

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.

Top 5 reasons to deploy VMware with Tegile

More from The Register

next story
Nexus 7 fandroids tell of salty taste after sucking on Google's Lollipop
Web giant looking into why version 5.0 of Android is crippling older slabs
Bada-Bing! Mozilla flips Firefox to YAHOO! for search
Microsoft system will be the default for browser in US until 2020
Be real, Apple: In-app goodie grab games AREN'T FREE – EU
Cupertino stands down after Euro legal threats
Download alert: Nearly ALL top 100 Android, iOS paid apps hacked
Attack of the Clones? Yeah, but much, much scarier – report
SLURP! Flick your TONGUE around our LOLLIPOP – Google
Android 5 is coming – IF you're lucky enough to have the right gadget
Microsoft: Your Linux Docker containers are now OURS to command
New tool lets admins wrangle Linux apps from Windows
prev story

Whitepapers

Why cloud backup?
Combining the latest advancements in disk-based backup with secure, integrated, cloud technologies offer organizations fast and assured recovery of their critical enterprise data.
Getting started with customer-focused identity management
Learn why identity is a fundamental requirement to digital growth, and how without it there is no way to identify and engage customers in a meaningful way.
High Performance for All
While HPC is not new, it has traditionally been seen as a specialist area – is it now geared up to meet more mainstream requirements?
Reducing the cost and complexity of web vulnerability management
How using vulnerability assessments to identify exploitable weaknesses and take corrective action can reduce the risk of hackers finding your site and attacking it.
Top 5 reasons to deploy VMware with Tegile
Data demand and the rise of virtualization is challenging IT teams to deliver storage performance, scalability and capacity that can keep up, while maximizing efficiency.