The following was printed in the January edition of the CVu journal from the ACCU, which is a great organisation of programmers that I would encourage you to look into.
In the last CVU Editorial Steve asked what pair programming is like as he had had limited experience, usually on one-off tasks lasting no more than an hour at a time and in all cases he’s found the required level of concentration to be extremely high – and it is. Three months ago I joined 7digital, a leading digital media delivery company, who’s development team use an agile approach including daily stand-ups, TDD and kanban boards, plus pair programming. In fact, the whole team pair programs as much of the time as is possible.
As Steve found out it can be quite exhausting, and I certainly discovered this after my first couple of weeks with this approach. We hold regular 1-2-1 meetings with the Development Lead and I mentioned this to him in my first meeting. He agreed, pair programming is indeed intensive, and it is counter-productive to be 100% focussed at all times, frequent breaks were recommended and the pair will generally break for 10 minutes returning to their respective machines to catch up on office email, read a little Twitter and some blogs before jumping straight back in ready to focus once again. I would say it is similar to the concentration techniques out there such as Pomodoro, whereby you focus solidly for a set amount of time, then break, which is an interesting technique that I have tried in the past and actually found myself to be achieving more.
One other thing I brought up in my 1-2-1 was that I tended to take a more ‘passive’ role in the pairing – watching and commenting rather than coding. As I was new to the code base this felt like the right approach to take, but as is always the case, the learning does not sink in until you actually type the code yourself. One method to increase my participation was a
‘ping-pong’ pair programming approach, whereby one developer writes a failing unit test and the other developer writes the code for it to pass, which fits in excellently with our TDD approach. But, all in all I needed to work on being more assertive. As my Lead had stated, pair programming is a skill just like any other and it must be learned and honed for the benefits to be reaped.
Also on the personal side, pair programming got me up to speed with the code base extremely quickly, and with pairs swapping once or twice a week, I got an overview of many parts of the system far quicker than if I’d been programming alone on a single feature. I also got to know the team which is a massive bonus as there is so much to be learned from your colleagues.
On the business side, we have reported a huge decrease in bugs reaching production and thereby a marked increase in customer satisfaction. The ‘second pair of eyes’ which your partner provides is hugely valuable – how many times have you found yourself going in circles trying to track a bug down only to find it was a silly typo or something just as obvious? Your pair is your saviour in these situations and they more often than not point out the mistake before it gets to compilation and nowhere near production.
The changing of pairs may sound chaotic, but what usually happens is is that one person ‘owns’ the story and partners switch around. The advantage of this is knowledge transfer. Of course, at first there is a small part of needing to bring the new partner up to speed, but then they can jump straight into assisting with development. If it takes too long to bring someone up to speed, then your task is too big or your approach is too wieldy, either way it needs to be reassessed, which you can do with your partner. This hands-on approach to knowledge transfer is far more effective than on the oft arcane “handover document” usually written just before you head on a 3 week holiday… As an example there was a piece of work to allow for gift card purchases, broken down into many stories but with one overall Minimum Marketable Feature (MMF) and a colleague ‘owned’ this piece of work with at least 3 other developers having paired with him on it and I was one of them. He took a weeks holiday during the development of the MMF and for that week I took over the ownership of the work pairing with one of the other guys and we continued it through to near completion without a hiccup nor a “handover document” in sight. From a business point of view the work did not need to stop or even slow down noticeably while he was away and the knowledge of the implementation is spread between at least 4 people. From the Dev’s point of view he got to take holiday when he wanted and without rushing together a handover on the afternoon of his last working day.
As with all methodologies it is not a silver bullet and relies heavily on the attitudes of the developers involved. If anyone prefers to work alone – building empires of arcane code, then they will find ways to continue to do so and make their pair miserable in the process. In fact, there’s an excellent list of
10 ways to Kill Pair Programming, which I suggest you read – and do the complete opposite of everything stated.
Your pair is your reviewer, your counsel, your sounding board, your mentor, your student and the person keeping you focussed. There is one thing though that I do miss from coding alone, and that is listening to music with my headphones on, but I can happily trade this for the benefits listed above.
Chris O'Dell 