Feeds

The perils of pair programming

The Agile Iconoclast goes solo

High performance access to file storage

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.

High performance access to file storage

More from The Register

next story
Windows 8.1, which you probably haven't upgraded to yet, ALREADY OBSOLETE
Pre-Update versions of new Windows version will no longer support patches
Android engineer: We DIDN'T copy Apple OR follow Samsung's orders
Veep testifies for Samsung during Apple patent trial
OpenSSL Heartbleed: Bloody nose for open-source bleeding hearts
Bloke behind the cockup says not enough people are helping crucial crypto project
Microsoft lobs pre-release Windows Phone 8.1 at devs who dare
App makers can load it before anyone else, but if they do they're stuck with it
Half of Twitter's 'active users' are SILENT STALKERS
Nearly 50% have NEVER tweeted a word
Windows XP still has 27 per cent market share on its deathbed
Windows 7 making some gains on XP Death Day
Internet-of-stuff startup dumps NoSQL for ... SQL?
NoSQL taste great at first but lacks proper nutrients, says startup cloud whiz
US taxman blows Win XP deadline, must now spend millions on custom support
Gov't IT likened to 'a Model T with a lot of things on top of it'
Microsoft TIER SMEAR changes app prices whether devs ask or not
Some go up, some go down, Redmond goes silent
prev story

Whitepapers

Securing web applications made simple and scalable
In this whitepaper learn how automated security testing can provide a simple and scalable way to protect your web applications.
Five 3D headsets to be won!
We were so impressed by the Durovis Dive headset we’ve asked the company to give some away to Reg readers.
HP ArcSight ESM solution helps Finansbank
Based on their experience using HP ArcSight Enterprise Security Manager for IT security operations, Finansbank moved to HP ArcSight ESM for fraud management.
The benefits of software based PBX
Why you should break free from your proprietary PBX and how to leverage your existing server hardware.
Mobile application security study
Download this report to see the alarming realities regarding the sheer number of applications vulnerable to attack, as well as the most common and easily addressable vulnerability errors.