In our next episode of the smash hit series “Coding Zealotry” (aka “The Random Babbling of a Madman”), we’re looking at the practice of peer programming (pair programming) and asking ourselves whether we should abandon our solitude and do it all together.
Peering Into the Paradigm
In case you’re uninitiated, peer programming involves two programmers sitting in front of a computer, writing the code together. Usually one guy writes and the other guy points out all his errors. Depending on the chemistry it can be a fun session of engaging on unique ideas, or a world war of spats over variable names.
The basic premise of the practice is that two sets of eyes are better than one. Firstly, you can in theory save hours of debugging time because the “peer” will see issues early while you’re still writing the code. Secondly, it can help move the project towards a more correct solution, because two developers can shake around a few ideas together until they somehow combine the best of both. Lastly, you develop knowledge sharing, both in a training sense, and also in having more than one single developer understanding the code base and the mind-set behind certain structures.
When it Starts Going Pair-Shaped
So, I worked with a development house where it was decided that the practice would be implemented 100% throughout the development teams. Being the obnoxious mule that I am, I resisted straight away. Honestly, I knew straight away that it would cost the business, and to be honest, I didn’t even enjoy it that much. I was told that studies showed that some small outlier of developers were not suitable for peer programming – there was obviously just something wrong with me, like those sick people in World War Z.
Now I’m not really here to bake my cake, but rather to deal with simple black and white facts, because facts are always black and white. Pause for effect. If peer programming really pays itself back, then I can’t argue. But does it?
Killing Two Birds with One Stone
There’s no denying that peer programming has its place in development.
Firstly, we have the classic student and guru relationship. A new junior joins the house, and frankly they’re a rabbit in headlights, and no amount of Google is going to show them where to start, which programs to use and what measurables mark their effort as complete. While video is a nice form of learning, little beats the effectiveness of watching a more senior developer implement code and find their way around the application, followed by some hands-on-deck under a watchful eye.
Secondly, seriously difficult code usually benefits from two minds debating or even fighting their way through ideas. Sometimes one developer wins all the arguments, through genius or brutality; other times you end up with an interesting merge of two mixed contributions.
Lastly, as a side note, peer programming also works as peer pressure. Checking your Twitter feed every 5 minutes suddenly seems a lot less appropriate. Code practice and company policy also finds its way into a lot more limelight.
Unravelling the Jumper
But let me get to my point: peer programming doubles your cost, so it must double the output. And that simply does not happen on a routine basis. You can argue, but for me it’s fact. Yes, there are success stories, but for every Facebook there is a trail of failed wonder ideas.
A) Over-Analysis
Peer programming is designed around discussion, and much of the time it generates too much of it. When two developers get on well, their discussion often wanders all over the place, and when they don’t get on, coding becomes a wade through the bogs. The development rooms also become a noise fest, with conversations overlapping, and when developers start arguing, the conversation circle rapidly widens.
B) Personality Mismatch
My view is that developers are predominantly introverts, and by definition, introverts find that social interaction is an energy drain. They usually started out as goggly teenagers locked in their rooms fiddling with tech, instead of moshing with friends at concerts. If they loved social interaction that much, they’d have chosen more people-based careers. I’m generalising of course – there are many who love to mingle, but there are many who can’t maintain it for long periods. So use it when it suits, not as a general rule.
C) Boredom
Developers are hands-on, pro-active people. They want to fiddle, get their hands dirty, rat-a-tat on their keyboards, try stuff, fix this, finish that. Peer programming requires you to spend half of your day with your hands at your side, reading stuff. It’s a recipe for tedium and mid-life crisis.
D) Diminishing Returns
As pointed out with the training advantages, peer programming is a great launch-pad for developers learning their game, or learning a new framework. There are clear early gains, but as the code or the skills improve, it no longer pays itself back. Like all “best practices”, you use them until the cost outweighs the benefits, and then you ditch them.
