Two heads are better than one

June 13, 2009 at 2:30 pm 2 comments

The beginnings of this post were when a colleague asked me to send him a brief snippet about Pair Programming and its benefits. While the snippet I sent him was mostly definition oriented, it did get me thinking that it would make a great blog post. And so here it is.

Pair programming is an agile concept and is frequently used in XP (eXtreme Programming). At its core, it is nothing but having two people sit and code instead of one. And while that may seem like an obvious timesink and a doomed concept, considering two people cannot type and code at the same time, it is surprisingly effective for many reasons, some of which I will try to outline with examples from my brief experience.

When you work as part of a team, there is usually a process (sometimes a series of flaming hoops even) which you have to jump through before you can submit your new, super amazing, code which breaks all previous latency records. Or something just as amazing. And for a lot of groups, that involves a code review process, where someone familiar with the architecture of the system or understands the programming language and the problem goes through your code, points out issues (as if there are any in my code !!!) and so on. And while this is a good way to ensure that the quality of code that is submitted to your code base remains above a certain threshold, it becomes a huge timesink. Especially the more you know about the codebase, as everyone and their aunts start sending code reviews your way.

How is this solved with pair programming, you ask ? Well, consider this. While pair programming, assuming one guys starts coding away. What does the other guy do ? He (aha, you shout, as you understand even before I say it) reviews the code as you type, suggesting corrections and optimal solutions in case you start going down the wrong route. But then, you ask, isn’t that a huge waste of time, considering you are basically getting one person to just sit and permanently review ?

Here is where the beauty of pair programming really shines. Its called pair programming for a reason. For one, both programmers take turns in writing up new code, while the other looks on and makes sure the code is up to the amazingly high standards. Another, how many times have you written this super awesome function which took you half an hour to think of, only to find someone tell you in a code review to use this existing library function that does the entire same thing ? Now imagine that guy is, instead, sitting right next to you and telling you this before you even start coding this up.

Furthermore, what if I am a new guy joining a team with a very stable, settled code base. How do I hit the deck running, other than sitting for hours reading up on documentation ? Well, I go find a senior guy who loves pair programming (which is easier than it sounds if a team loves Agile practices) and go pair with him. Instant knowledge dump, and easier transition. This was the case with Arthur, a guy who joined our group for a short period of time. Instead of spending, say two weeks reading design and architecture documents, we started pairing with him from day one. By the end of day three, he had already fixed two bugs (both of which were on the first day itself!!!) and had made quite some headway into designing his first full feature. Now this intensive pairing (some might even call it hand holding) might have caused us to loose some productivity in the first few days, but by the 4th day, we had a new engineer who was capable of working independently if need be while pairing on the initial designs and features.

Also, Pair programming helps increase discipline and productivity. How you ask ? Well, I tend to loose focus quite easily, and love to be caught up on my emails (the thousands that spam me everyday, sigh!). And replying to my IMs takes precedence, often interrupting my thought process. Now I was pairing on the other hand, out of respect to my pair, I usually end up closing all such external annoyances, and often get two to three hours of uninterrupted work. Does wonders for my productivity, which is why I often roam around look for people to pair with.

Of course, if you need to convince management why you need to do pair programming, you need but point them at the multitude of studies that have been done which show an increased quality in software developed while pairing as compared to individuals. Also, if a person ever does end up leaving the team, there is someone on the team left who has paired with him and thus there are no systems which are alien to everyone on the team ever. And hey, its fun to pair, think out loud and bounce ideas off of each other. Seemingly impossible problems may seem easier as well when you pair. Often times, I seek out a teammate to bounce ideas off of, and more often than not, he will say “Alrite, let me get my keyboard. Lets pair on this.” Then it would take two hours to churn it out, and we would have a working, tested prototype by the end of it.

Of course, on the other hand, there is the intimidation factor of pairing with someone who seems much more knowledgeable and would eat you for lunch. Not to mention possible ego clashes and the fact that some people might find it akin to tutoring if they are paired with someone new. But these are pitfalls that can be overcome quite easily with a dedicated team.

And pair programming works really great when you do Test Driven Development. TDD is the art of writing a failing test before going and writing just the amount of code to pass the test. When you practice something known as ping pong pair programming with TDD, it becomes quite interesting and fun. In this, one person writes a failing test, and then the other person goes and writes the bare minimum code to get the test to pass (That is the key, the bare minimum. Don’t do speculative programming). And then, they switch. So the guy who wrote the code the first time now writes the next test, and the other person implements the functionality. This ensures that both people get turns at writing code and tests, and can make sure they cover all the cases. You end up with well tested code, but just enough code for your need. No speculation, no unneeded generalization, nothing extra.

And of course, no agile practice post is complete without an obligatory dilbert comic, so here goes :

Dilbert on Pair Programming


Entry filed under: agile, pair programming, refactoring, testing. Tags: , , .

Coverage isn’t everything Separation anxiety ?

2 Comments Add your own

  • 1. oogtech  |  July 19, 2009 at 9:14 am

    Yes! This is right.

    Yet… To be comprehensive, I think it’s nice to point a couple of things about pair programming and TDD:

    1) Most technical managers readily believe pair programming increases quality. What they wonder about is productivity.

    Not all companies have a quality problem with their code. Paradoxically, I work in a company where the work process generates endless piles of bugs – yet the company is a market leader: they have tester teams, their customers have testers teams, and although programmers like me tend to get very unhappy about the situation, there is not actually a business problem.

    On a completely different line, I write and promote software in my own time. This is a do or die activity. I get strict when it comes to keeping code modular, but I don’t do TDD (and can’t afford pairing). Modular warrants that, when the s…t hits the fan, it’s actually hitting one out of many many tiny fans. TDD I use not, because the essence of quality (from a user’s perspective) is what the software does, and how many bugs software can tolerate before quality is actually affected.

    If I build a rocket someday, I wll use TDD and cleanroom software. No bugs is great! Point taken.

    2) If a company doesn’t use pair programming, they may not have time-consuming code reviews either.

    I totally join in when it comes to avoiding distractions. Active pairs (programming or not) are much harder to distract than isolated workers. Distractions are a huge productivity sink at work – there’s been a good study showing that it takes 15 minutes to get fully concentrated after an interruption, aggravated by the fact that workers on an open floor office get distracted about every 15 minutes(!). Maybe that stands as one of the greatest, unproven arguments suggesting that pairs program ‘at least twice as fast as individuals do’.

    Yet it may not be fair to oppose pair programming to long code reviews – not having pair programming doesn’t imply having lengthy code reviews, and having neither is not wrong in all respects… Single programmers own their mistakes fully, and as far as I know, companies that dedicate an extensive amount of time to code reviews probably overlook the fact that few programmers would time-bomb themselves with poor code.

    Generalising specialists are created by rotating developers and common codebase ownership. Having a specialist handy may teach you less about a special problem than solving it yourself.

    3) Last, but not least… It would be great if people acknowledged more often the social bias involved in pair programming – never mind open floor offices.

    I seem to remember a lost era when the image of ‘bedroom geniuses’ coding smart stuff in their own corner was not unrespectable in the programming community.

    One thing I love about new methodologies and processes is that they potentially open doors to different kinds of people. One thing I’d hate is seeing lonesome vi-slingers mobbed amidst a gregarious ‘simple and social is code’ epiphany,

    Don’t get me wrong. I love this stuff – a devil’s advocate is whispering in my ears.


    • 2. shyamseshadri  |  July 20, 2009 at 11:45 am


      Completely agree on some of the points you raised, and that devil’s advocate is usually permanently resident on my shoulders, so I know where you are coming from.

      1.) With regards to productivity, as I mentioned, Pair programming is not for everyone. There are people I know on my team (me included), who are far more productive when they pair than when they are not. This is not due to the fact that they can’t work independently, oh heaven’s no. Its mostly because of lack of focus. Its easier to get in a 2-3 hour slot of pure productivity as compared to sometimes getting distracted when working independently. Would I recommend pairing all the time ? Hell no. I find that if I pair maybe 2 – 3 hours a day, and then work on my own the rest of the time, I get the most work done.

      As for TDD, I will be the first one to say that doing TDD will not keep your bugs away. Because there is no way to cover or even remember what cases are possible. TDD just gives me confidence that when I finally hit play, it won’t blow up for the silliest things like forgetting an operation or method call. When I write things with conditionals or tricky operations, TDD is my safety net to fall back on. Trivial stuff, I usually don’t bother.

      2.) Well, even ignoring the fact that they might not have lengthy code reviews, I still find the fact that not having what you call generalizing specialists and common codebase ownership can be extremely fatal when that specialist goes on leave (happening right now with me, in fact…). I have had times when I worked solely on a part, and then when I went on vacation, things blew up and people had to spend a day trying to patch a trivial issue. And its not the fact that few programmers would time-bomb themselves with poor code, its the fact that they don’t know any better, not having been told there’s a better way (I was guilty of this when I initially joined). This is especially true if you hire a lot of new grads.

      3.) I love vi-slingers. I love vi, in fact. And if someone tells me to pair all the time, I would be the first one to tell them to take a hike. Fact of the matter is, there are times when we need to sling some code on our own, and pairing or teaching someone else would just be a hindrance. In those cases, sling away. Don’t let anyone tell you otherwise. But just don’t frown upon pairing completely, because its often a useful and underused technique, and best of all, can help get you someone else who can maintain what you just wrote :D.

      Finally, I moved blogs, so find all my new posts from now at
      Thanks for commenting.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed


Blog Stats

  • 5,606 hits



June 2009
« Sep   Jul »

%d bloggers like this: