Caution, this blog may be ironically named

Pair Programming, Peach or Plum?

| Comments

I’m currently in my third week of pair programming and I wanted to talk about some of my experiences, both positive and negative.  I pushed for a pair programming ‘experiment’ at work but I was dubious as to its value and usefulness in the cut and thrust world of professional software development. So the justification for it seems a good place to start.

Two Expensive Resources Working Slower, Yeah Right!

Let’s not beat about the bush, pair programming means that two expensive resources, developers, are tied up on a task without necessarily bringing two ‘man days’ to a task.  What pair programming aims to do is reduce the overall cost of ownership of code.  It can work as a mentoring technique to develop less experienced programmers but this maybe defeating the object of the type of pair programming that really brings value.

In a traditional software development lifecycle the cost of fixing a bug rises exponentially as you move through the software’s (or feature’s) lifecycle. I’m sure we’ve all seen a graph similar to below at some point in our careers. It shows the costs of fixing a bug versus the stage development is currently in.


The aim of pair programming is to raise the costs slightly at the start, with a view to reducing the sharp curve towards the end.  So we end with a smoother curve and we spend list time in the costly area of the graph.

The Good, the Bad and the Ugly

My experience has been overwhelmingly positive, but the ones that stick out the most are:

  • More Focused – I’ll admit I have problems concentrating at times, I’ll see a tweet, Google something related to what I’m doing and find an interesting blog, etc.  Working in a pair has really focused me on the task at hand and I think I’m more productive.
  • Less Rabbit Holing – I’ve found just verbalising my ideas about what I want to do with a design, refactoring or while investigating a bug helps to work out problems or see things I’ve missed.  Also, the navigator can ask questions about less clear areas.  All leading to a better design, bug fix, etc.
  • Differing Styles – Participating in or watching someone else’s thought process has helped show me areas where I could improve and given me new approaches to try when blocked.
  • Naming – One thing I struggle with at times is how best to name things to best express my intentions, having a partner to ask “this is what this does, do you think that’s descriptive?” .  All this leads to better and more maintainable code. The not so good:

  • Breaks – It can be awkward to be stuck to someone else’s brew up times, smoke breaks, lunches, etc.  It can break the flow and make it feel like you’re spending time waiting on others.

  • Thinking Time – This is very subjective and probably should be a pair activity, but sometimes when confronted with difficult to understand legacy code, a strange bug or just several choices.  It’s nice to go through your ritual, whether that be listen to your favourite music, rock the water cooler or chat to that cute girl in marketing, it all has the same outcome you feel better and have had thinking time.  I’ve found this particular hard when your partner is looking, listening, questioning and waiting for you to carry on. Overall, it’s definitely been a worthwhile experience and one that I will be continuing.

Remember It’s Not For Everyone

We’ve been careful to explain to people that it is not an experiment with a view to introducing it across the team, just something we wanted to do.  It started off with just two of us but a third has joined with one or two more interested in joining if the opportunity came up.  But it’s important you don’t force the issue.  For it to be a success you need people who:

  • Check their ego at the door – There is no room for “this is the way I do it and it’s the right way” one of the biggest take aways for me has been learning from someone else’s style and approach, even if I disagreed.
  • Are Interested – This is so important, for the navigator role to work well the person needs to want to do it.  Not just be sat thinking “God, when can I drive”.
  • Be Strong – I have a strong personality and it can over power people around me.  As much as I’ve tried to rein it in when working with less strong personalities, it’s still important the other person is strong and is willing to defend their opinion.