Pair Programming Benefits and Costs

A new pair programming study (Arisholm et al. 2007) indicates that that the practice neither increases quality or reduces costs, in general.

The results of this experiment do not support the hypotheses that pair programming in general reduces the time required to solve the tasks correctly or increases the proportion of correct solutions. On the other hand, there is a significant 84 percent increase in the effort to perform the tasks correctly.

In specific contexts, like junior programmers pairing on complex tasks, pair programming results in significant increases in quality. However, in other contexts the increase in quality, if any, comes at a high cost. The study doesn’t appear to support the conclusions described in earlier XP research. Specifically, that a team could expect "a 15% increase in development cost for a 15% improvement in quality". This earlier study used students rather than professional programmers and the strength of some of the researchers' techniques and conclusions have been questioned.

My own personal experience is that I enjoy pair programming for some activities and in some contexts, but not in all contexts. On complex tasks, I enjoy pairing with other senior developers for collaborative problem solving. It’s not as enjoyable, but I also see benefit for the team when pairing with junior or less skilled developers for some tasks. The less skilled developer may provide the occasional useful input often I feel the collaboration is a net loss in productivity. For example, let’s say we’re working on functionality that uses several advanced technologies. If my pair is not skilled in these technologies then the pairing will probably not be a net productivity increase. You could say that it’s valuable for training the less skilled developer in these technologies. However, I’m speaking about the case where the less skilled developer has already had extensive opportunities to learn the technologies in question and has not been successful. "Training" by pair programming will generally not solve this problem, in my experience.

When developing simpler functionality, I see more benefit from testing and specifically from test-first and TDD techniques than pair programming. For the either/or types of people I generally enjoy collaboration and I’m not the type that wants to work in isolation from the team. Pair programming is only one specific form of collaboration. I’ve worked exclusively in open work areas for the last 7-8 years and worked in those environments several times before then. I like that work environment very much and although I had the option to have an office I choose to sit with the team.

I like Martin Fowler’s perspective on pair programming. He says "my view is that you should try it and the team should reflect on whether they feel they are more effective with pairing that without". I’d also recommend that the team discuss in what contexts they feel they are more effective or not.

Leave a Comment

Mastodon