Evaluating Pair-Programming

I’m glad Andy side-tracked into talking about us temporarily dropping pair programming – I’ve been considering the same kind of things but want to see what the rest of the team thinks about it before I say too much.

Slightly off topic, the development speed we’re achieving now is making me wonder if the tradeoffs when developing purely under Pair Programming are actually worth it.

There’s a lot more that has changed recently that has led to our sudden improvement in velocity – not just pair programming. For a start, we’re more focussed on the task because we’re not sharing the support load around the entire team. Plus, the business has really started to understand how difficult it will be for us to get things done so they’ve gotten off our backs about everything else and really focussed on hitting this big scary deadline. We were splitting our development efforts between two or three products and the context switching was killing us.

Another thing to remember is that right now the two most experienced people with the codebase are doing the development and the other two are handling the support and other miscellaneous support tasks.

Even the features we’re working on have probably contributed. Andy has been starting the work on the UI - a well known area that requires attention to detail but doesn’t tend to ambush you with unexpected challenges all the time. Meanwhile, I’m finishing off a section that we’ve spent the past couple of months laying the ground work for. I suspect that much of the high velocity I’m seeing at the moment can be attributed to the hard work we put in earlier to keep the code quality up and stay code debt free. All of a sudden instead of working in a big scary area with no tests and any change might be your last – I’m working in a nice safe harbor where there’s a ton of tests to tell me if things go wrong at both the acceptance and atomic levels.

So there’s a bunch of things that have fallen into place nicely, but that’s not to say that pair programming wasn’t impacting our velocity. The problem we are going to run into soon, is that we’re going to have Doug and Jack back on the core development as we bring in new support resources and get them trained up. Then all of a sudden half the team is fairly new to the code base and that lack of knowledge sharing is really going to start hurting.

Even more short term, we have the challenge of bringing the new engineers up to speed on the products, the code bases, company policies and all the rest of the training and mentoring that new recruits need. That work starts on Monday and the faster we can get them up and running to handle support, the better our chances of making that big scary deadline.

As a team, we need to develop our training and mentoring skills so that we can knowledge share – either through pair programming or some other means, far more effectively. Before we were doing pair programming, I was spending a huge amount of my time helping other people learn about our code base – that cost can’t be ignored either.

The advantage we have is that by the end of the quarter, all going well, we’ll have gotten rid of this big scary research feature and moved onto work that we better understand, can better estimate and doesn’t require a PhD1 to understand the details of. We should also have support under control and we can start focussing our attention back on adopting XP and improving our practices. The big problem we’ve had for the past couple of months is trying to do too many hard things at once and burning out – support, the big scary feature and adopting XP. That’s why XP has sustainable pace as a key ideal – we’re currently focussing on getting that practice right in difficult times.

1 – or reading PhD dissertations↩