To Pair or Not to Pair?
Of all the aspects in the world of agile methodologies, none has raise more discussions than that of pair programming in XP, eXtreme Programming. There are many studies in this area and it shows there could be benefits from pair programming. However, Karl Wiegers, in Peer Review in Software, argues that pair programming is not a real review technique and does not really create anything other than an informal review at best. This view has valid concerns since there is no outside review of the code other than the two developers creating the code. But to give us a common starting point let’s look at pair programming not from a functional review perspective, but from a productivity and quality view.
The studies have shown there can be a very good gain from pair programming. Alistair Cockbrun and Laurie Williams did one of the earliest studies I found, The Cost and Benefits of Pair Programming (found at http://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia.PDF). This study defines under what conditions pair programming can have a good ROI. To put it simple: if the pair can have a productivity of 85% of the two programmers working individually and have a 15% better quality then there is a ROI on pair programming.
The problem I have seen is that many shops do not want to collect productivity and quality measurements. Without keeping an eye on these measurements there is no way to know for sure if pair programming is getting a ROI. On that note, there is no way to know if even individual programmers have a ROI without doing some sort of measurements.
In one of the shops I worked, pair programming did not have a good ROI. For example, on three different occasions what was quoted to be a one day task turned into a two day task because my other pair wanted to “fix the broken windows” before doing the task that was assigned. What we ended up doing was adding three days to a project that was already late. This is not good for any project, especially one that is late. In other shops I have worked we have did pair programming in an informal fashion. Meaning sometimes we did pair programming and sometimes we did not. Pair programming was taken on as the project, or task, required it. In that shop we only missed one project date in over three years.
In short there are good and bad aspects with any process, you just need to make sure that the goals of on time delivery and customer satisfaction are kept as the target and you will overall hit the mark. The important thing is not to sacrifice these goals when crunch time comes. As Edward Yordon said, in Decline and Fall of the American Programmer, at crunch time a business will show its true commitment towards its quality process. Only truly commitment businesses will stick to these processes in crunch mode. Go ahead test the business you work for and see where its heart is. Each of us can change the way the business does it job if we just stick to our standards.