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.