Deciding to use Pair Programming

During the construction phase of our project, the team decided to use XP. Of the 12 XP activities advocated in the first edition of the XP book we used 9, choosing to skip the metaphor (since we already had a solid architecture), simple design (not that we advocated complex design, just forward thinking), and having an onsite customer (since our customer was...not on site). Of all the XP practices, the most controversial for the team (and probably everyone else in the world) was pair programming.

According to our estimates, the schedule was extremely tight. We weren’t sure whether we would have enough time to complete all the features, let alone complete them working in pairs. Luckily I was introduced to some interesting data through a class I was taking, Significant Papers in Software Engineering taught by Mary Shaw. One of the papers we read was an article by Laurie Williams, Robert Kessler, Ward Cunningham, and Ron Jeffries titled Strengthening the Case for Pair Programming (PDF) and published in mid-2000. The data was a little old, but the essence of programming in pairs hasn’t changed that much.

The paper outlined two interesting findings which had a direct impact on how we might work during the summer. The first finding was that pair programming requires only a little more effort than programming alone. This study found that pairs require between 15% and 80% more programming hours to complete a task, not 100% more hours, than programming alone. In the data presented, a pair would usually start out requiring more effort and over time become more efficient, almost but never quite to the point of a single programmer. The second finding complements the first - pair programming gets work done faster. This study found that pairs are between 20% and 40% faster than programming alone. And on top of all this, the code quality was found to be superior compared to programming by on your own!

There were some problems with the data presented that made me skeptical. The first was that the projects used in the experiment were really just toy programs - small applications that were self contained and can be started and finished in a few hours. The second problem was that the teams were made up of undergraduate students with little to no industrial experience. The most novice person on the Square Root team has just over two years of experience and the team average is over three and half years. That’s three and a half years of coding habits (both good and bad) that we would have to reconcile to make pair programming work - something the undergraduate teams didn’t have to deal with as much.

With these things in mind, I created some projections to see if we could even afford to use pair programming, assuming the Square Root team performed similarly to the teams from the experiment. As you can see from the graphs, the findings were interesting from a planning perspective. The team decided that we were going to use some kind of code review, either pair programming or Fagan inspection.


In terms of effort, if the team operated in the 15% efficiency range, it was conceivable that pair programming would require less overall effort than Fagan inspection.


In terms of completion time, it appeared that we would be able to write more lines of code faster with pair programming than working alone (individual LOC/hour is derived from previous MSE studio rates in Java).

With these projections in hand, we decided to commit to pair programming for the first two iterations. Personally, I was extremely curious to see how we compared to the numbers presented in the paper. So, following the first two iterations, I pushed hard to conduct an experiment. Our experiment combined informal replication and lessons learned approaches to assess the efficiency of the Square Root team compared to the previous experiment. I’ll talk more about how the experiment was set up, the specific results, and what we learned in future posts.

Creating some projections on how pair programming would affect the team's plans turned out to be a great way to create buy-in for the process and instilled the team with more confidence. I don’t think pair programming would have been used as much had we not created these early projections to show that it wouldn’t completely explode in our faces and prevent us from finishing the project by the end of summer. On top of that, these projections and the data presented laid the groundwork for a series of interesting experiments that further solidified the team’s processes and use of XP.