Pair Programming - Luxury or Necessity?

I was recently contacted for advice on how to justify utilising pair programming on a project, as the client was very nervous about the benefits and was seeking some reassurances. It raised all sorts of questions, which I checked against my previous experiences to see if any empirical answers can be found as to the relative benefits.

The very first question is at the heart of this issue is ask what an “agile project” means? To some “agile” means taking parts of the overall philosophy, to others it is embracing all elements. Often the hardest agile question to answer is to pair or not to pair?  Over the last three years I have worked intermittently with a company that is agile in all senses and does pair programming, running five teams, each with up to six developers. We continually discuss how to improve productivity (velocity) and are always seeking ways to improve not only development performance but also the interactions with the more “waterfall” parts of the IT organisation, but interestingly we have never questioned whether pairing is justified or not, we just accept that is the way we should work.

My next question is why pair program at all, as it seems, at least on the surface, to be expensive? To me the costs fall into two camps – firstly, and the easier to quantify is the cost of recruitment. Pairing requires not only technical skills but an ability to co-work with another each day and so selecting the right individuals is paramount and requires a good process which is time consuming to administer and you need to accept the ratio of acceptances to rejections will be low. But is this a cost of pairing or just something every software company should do to ensure quality staff? With pair programming you don’t have the luxury of just shunting someone in the corner and either giving them selective work or leaving them alone, as the person is working with someone else so a below par performance means at least 2 days work lost per day, and at best other staff not willing to work with the person or looking to move on. For me this expenditure is no more if you pair or not, getting recruitment right is a cost all good software companies accept as the returns in terms of better delivery significantly outweighs this cost. The second cost I guess is the really contentious one – are two developers working together more or less productive then working alone? As with the most basic development questions there is no empirical evidence to look to, so let’s consider the benefits. The very obvious is the adage “two heads are better than one” and no one can seriously question the benefit of at least bouncing ideas off others. But agile is more than this and one empirical measure you can put in place is the number of bugs founds post development deployment. If you aren’t pairing yet and want to try this then I recommend this as a very easy metric to put in place.

The real killer benefit to me of pairing is that the code has to be well documented and easy to pick up as it is regularly worked on by different developers, and allied to refactoring with automated testing, keeps the code in very good state and avoids legacy code whereby nobody actually knows what the application does and cannot change for fear of breaking what currently works. I agree this can be achieved without pairing but it is a lot harder and you won’t actually know you’re not in that state until one of your key developers leaves. I view pairing as an investment to keep the application in a serviceable condition so that the business is not exposed, if you like, it can be thought of as a very reasonably priced risk mitigation cost.