Pair Programming – My perspective.

Pair of farmers working the rice, Ubud, Bali, Indonesia: Martin Harris
Pair of farmers working the rice, Ubud, Bali, Indonesia: Martin Harris

I have done quite a bit of XP and Agile.  One of XP’ engineering practices is pair coding, At first I just did not understand pair coding.  My initial introduction was within a self directed team practicing Scrum and Agile.  I have come to realise that without self-directed teams, you don’t have scrum. You can scrum without pair coding but without these, you have thrown away two very effective techniques.  What is left just turns into inefficient micro management.  For some reason, these two techniques get resisted hardest.  Yet they are the key and the dynamo behind the success.

My definition of Pair Programming: A technique to increase development throughput by maximizing review coverage, reduction in faults leading to increased software quality and less effort in downstream processes such as manual testing and product maintenance.

Pair coding viewed from the outside is often seen as a waste.  Its important to understand the process before eliminating it.  Two guys working at the same desk!  What a waste of effort! I find this a little odd.  In programming circles its quite difficult to be a team, when most of the time is spent isolated at a development console.  There are points in the scrum process when the team comes together for a group activity, but its a small part of the overall process.  After an iteration planning session the team returns to their islands to work.  Quite peculiar if you think about it in the context of other professions.  I would say that there are plenty of examples where people work alone but in software development the best work is done by teams, and a pair is the optimal small unit within a larger team.

Good though it is pair coding should not be mandatory, the team should decide which aspects of the work require the higher pitch of pair coding, and which bits can be left to individuals. There are many tasks that are not actually writing code, some of these can be done individually.  Saying that though, a good scrum master knows pair coding is hard, and most people will revert and poor quality code will result, so it should be encouraged. Make it a natural part of your work and attempt to write all the code this way.

I have found there is a temptation, to reduce the levels of pair coding when the team is under pressure, this is the wrong approach. Actually you need more pair coding if you want to go faster. In addition the increase in quality will reduce the number of defects and lower the number of production support issues.

Pair programming distilled

As I said before initially I was skeptical.  This is what I now believe.  These points can also be found in greater detail in the linked pages below.

  • Pair coding is a review process. While one developer concentrates on the mechanics of writing the code and getting the confounded IDE to do what he requires, the other is thinking quality and strategy.  You will often see pairs break to discuss a point of quality make a decision and move on.  If you reviewed someones code at a later stage, and made the same decision.  i.e. all this has to come out and be replaced by better patterns and its going to cost you.  Also later never happens so the code remains poor.  It takes nerves of steel and many people pushing to get bad code changed.
  • When you have an equal pair looking over your shoulder you try much harder. Naturally you do, as if you don’t they pick you up on points of quality and that is irritating.  I strive all the time for quality in a pair or out, but I know I perform at a pitch higher in a pair.
  • Equal pairs are better than unequal. Mentoring a junior is fine, but that is not the best way to get quality code.  Although beneficial and necessary to educate team members the equal pair smoothly moves to excellence.  Whilst mentoring, the tutor reduces his pace, and is unchecked.  You will find statistics on the wikipedia ref that shows an improvement in correctness of around 15% and 20 to 40% decrease in time, but between a 15 and 60% increase in effort. Williams et al. 2000 also cites an earlier study (Nosek 1998) which also had a 40% decrease in time for a 60% increase in effort.  I know what this feels like, and to me it feels about right.
  • A secondary effect is a closer knit team, focused on delivery and quality.  The team really understands and enjoys the work they are doing.  They know where they are going.  Nobody is sitting to one side, struggling with something.  Brilliant software development is hard, and hard things are easier if there is someone with you.
  • The scrum stand-up seems to go better. People know each other and are comfortable.  They are more likely to come forward in the meeting to highlight an issue.
  • The team does less context switching. Pairing means working on less parallel tasks. Parallel working is hugely overrated and a massive waste. Pairing will help keep context switching down.
  • Its very hard work.  In fact its exhausting. Working this way is much harder, I don’t get to read my email, surf the web, call home.  Give me a break.  😉

So that’s my take on it.  Its worth it and it works but its hard work.

See the collection of links below for other views academic studies etc.

Definitions, studies and papers

Other peoples perspectives

How to start Pairing

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter
Google Buzz (aka. Google Reader)

One thought on “Pair Programming – My perspective.”

  1. Nice post! The point about the overall throughput increase is also one that I have experienced.

    “Its very hard work. In fact its exhausting.”

    Absolutely, and I found this from the first time I tried pairing in 2000. When I coach teams, though, I use a concept called “Core Hours”. That’s usually something like 9:00 AM to 3:00 PM or 9:30 to 3:30 with 30 mins to 1 hour for lunch. During that time, the team is doing nothing but work on the project. Outside of Code Hours, though, the team members can do any of the administrivia, phone calls, e-mails, general surfing, etc. that would distract them otherwise.

    The reaction of management is usually that they would like longer Core Hours, but that goes away after an iteration or two where they see the productivity actually go up when the team members are working 5 dedicated hours rather than 8 distracted ones.

    The Core Hours concept also helps with fatigue. If you’re only pairing for 5 hours of the day, you’re better able to rest and be fresh the next day. Of course, there’s flexibility around all of this – I wouldn’t tell a team that’s in the middle of something that Core Hours are over and they should stop!

    Dave Rooney
    The Agile Consortium

Comments are closed.