Pair Programming: Doing what comes naturally

Recently I’ve been having a multi-channel conversation with Mark Stringer over Email, Twitter, and coffee about whether Pair Programming is intuitive or not. There are many articles about what Pair Programming is (I like this one) but the short summary is: Two people, one keyboard, one computer, one mouse. One of the pair ‘drives’ (programmes) while the other observes. When the driver becomes lost or the observer has a clear idea of what needs to be done, they swap (usually every 5-15 minutes). Repeat until task is complete. Every half a day the pairs swap around so that one of the pair is replaced with someone new.

My view is that, whilst Pair Programming isn’t widely accepted behaviour, it is intuitive and ‘common sense’. Mark’s view is that, like the Frosbury Flop, it may be effective but is definitely not intuitive. Given that so many managers and developers I’ve met are totally against the idea of pairing – even those that claim to buy into many other Agile techniques – I have to concede that Mark may have a point. Maybe … or maybe its that Pair Programming is so different to the accepted behaviour of working in an office environment and ‘getting on at work’ that we suppress our intuition and stick with the convention of one person, one computer, one task.

As a programmer, before I’d heard about Pair Programming, I was always dragging people over to my computer to get their assistance. If I’d done a bit of design work I always wanted someone to help me validate it and challenge my assumptions, if I was struggling with a bug I’d drag someone in to help me find it, and if I was using some new API or working in an area I wasn’t sure about I’d go find an expert. Pair Programming meant that I could stop interrupting people doing their work in order to get them to help me do mine, and could stop being interrupted by others for the same reason. Bloody obvious if you think about it.

As a manager, before I’d heard about Pair Programming, I was always trying to get the team to talk to each other. I hated the idea that areas of a system were only properly understood by one person, no matter how clever, dependable, dedicated and healthy they were so I’d try and get them to talk people through what they were doing or ‘hand over’ if they were going on vacation. I worried that some of the code or tests might not be ‘up to scratch’ and so would try to get developers to do reviews of each others code. I was sure developers working in isolation would write very similar solutions to very similar problems so I’d ask people to do a ‘show and tell’ at the end of each week to let the rest of the team know about what they had been doing. Pair Programming meant I could relax a bit: code reviews were part of  code production, no one bit of the system was understood by only one person, and the architecture and design of the system was understood (and developed) by the whole team. Bloody obvious if you think about it.

So it seems to me that Pair Programming is a natural extension of the way many developers and managers normally work, formalised into a discipline that’s easy to follow. If you only achieve the benefits above, I believe it has to be worth doing but I also think pairing has some unnatural and unintuitive benefits. As a programmer I’m thrilled by the way pairing helps me to come up with creative solutions, to learn from other developers, and to have fun doing what could often be a chore when tackled on my own. As a manager I’m amazed at the productivity of Pair Programming. More than once I’ve seen teams get to the state of delivering one user story per pair, per day because everyone understands the problems and solutions so well and organises themselves into the most effective combinations on a daily basis. Funny how the inverse of these are often the arguments posed for not pairing: developers worry that pairing will restrict their ability to apply their professional skills and managers worry that pairing is simply two people doing one person’s job.

This is why I think its important that people understand that Pair Programming is a natural or intuitive thing to do. I’d say that over 95% of managers and developers I know who have actually tried Pair Programming love it for roughly the reasons I do. But well over half the managers and developers I’ve talked to about Pair Programming will not try it because they have already decided that its unintuitive and too far outside the normal boundaries of office working to be ‘common sense’. Sadly for them, I think they will struggle to achieve any form of Agility without it.


4 thoughts on “Pair Programming: Doing what comes naturally

  1. Mike

    I’ve found there are two underlying ‘territorial’ reasons why teams resist pair programming.

    1: Developers jealously guarding ‘their’ code (if they feel some sort of ownership of it) and the credit which they’ll get for completing the work alone.

    2: Managers jealousy guarding their power and sense of control. Managing two programmers at once leaves a manager feeling outnumbered and less in control.

    Both are ultimately immature motives but powerful nevertheless.

    1. pauldyson Post author

      Yep, I’ve seen both of these too. I think both stem from learned behaviour of office working and how to succeed in an office environment. I always tell my teams that we succeed as a team and we fail as a team and that any individual credit is earned by contributing significantly to the team’s success. This is hard for ‘superstar programmers’ in particular to accept; they’re used to working incredibly hard on their own and being measured by their ability to ‘go beyond the call of duty’ or ‘drag us back from the brink of disaster’. In my experience ‘superstar programmers’ are a liability, especially in an Agile team.

      Managers who think management = control are equally challenging. I had the privilege of working on a large and long project with a manager who showed me that management = facilitation and guidance. Managers control the constraints and parameters of a project, not the actions of the individuals working on it.

      Of course these things can be resolved in a team whilst still running counter to the culture of a company. In these circumstances the manager has to show they can recognise and reward individuals without affecting the togetherness of the team whilst simultaneously demonstrating to the powers-that-be that they are in control without micro-management. Hard but absolutely achievable.

  2. Pingback: James Thigpen / remote Pairing with microsoft SharedView

  3. Willem van den Ende

    Hi Paul,

    like you I’ve been pairprogramming long before XP. Back when I had a Commodore 64 I preferred to have a friend over to code together, or at least try out the results immediately.

    At university (computer science) pairing was the norm (on programming excercises etc.). I had never given that much thought, except that I found it very productive and noticed that I was able to solve much more difficult problems in a clean way with a pair (much unlike teamwork at the time, which I learned to do well repeatedly through XP).

    Today I’m pairing on a bit of javascript. I’ve dabbled with javascript alone, and now want to produce something that requires a (for me) major amount of it. I got something working (alone), and started pairing on it today, with someoen who has had even less exposure to javascript than me :). It’s great. Explaining the code I made, as well as explaining and exploring the code I downloaded teaches me a lot. It seems to go slower, for now, but I know:

    – my understanding is better (which leads to less bugs)
    – we are refactoring (also on downloaded code), because our discussion brings up unclear pieces of code
    – the solution will be more simple
    – I am/We are much less likely to get stuck. I often want to press on when working alone, which often leads to quick but unsustainable results.

    So for me, pairing is a no brainer. I’ve more or less stopped trying to convince people. Instead, whenever we do a workshop or training, we pair on presenting, coding, coaching etc. That seems to make it a lot more intuitive.

    Having said that, I still like to dabble on my own occasionally, especially when trying out a tutorial or something.


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