Posted by castelaz
on September 17, 2004 at 3:42 AM PDT
I dont know how it is for you, but nearly every conversation Ive ever had about extreme programming eventually works its way to pair programming, which pretty much kills the dialog part of the conversation. Pair programming is apparently best discussed in monologue format. For most of the developers Ive listened to, it is The extreme in extreme programming. It is either the single greatest advance in Western Civilization since the windowed envelop, or it is the spawn of the Netherworld.
Briefly, Pair Programming is what it sounds like, two programmers working together on the same computer. One is the pilot who does the actual coding. The other is the navigator who serves as both guide and companion. The programmers collaborate during the development session. They occasionally switch roles, so no one gets to monopolize the process. Its advocates claim pair programming results in higher quality code and increased programmer confidence. In addition, some experts believe these gains can be achieved with little or loss in productivity, while others go further, and hold that the pairs are substantially more productive than a single programmer working alone.
There have been a number of studies examining these claims. The current issue of IEEE Software has the latest, A Field Study of Developer Pairs: Productivity Impacts and Implications. The article is a reexamination of data collective during a previous study conducted by the authors. In the prior study, the researchers found that
teams are more productive when their members work independently. These findings where published just as agile development techniques with their promises of higher quality and increased productivity were gaining attention and serious study. Several subsequently published papers substantiated pair programmings claims, hence the desire to reexamine the data.
In the new study, the authors have to resort to a notion of concurrency. Since the data was originally collected prior to general knowledge of pair programming, it does not record when programmers actually worked together as a pair. However, the researchers could determine when developers worked on the same module on the same day. They called this concurrency, collaboration potential. Although the authors recognize the measure doesnt directly reflect pair programming, they argue concurrency is
a necessary precursor, positively correlated with collaboration
. In other words, its the closest measure of pair programming the data will yield.
As to the findings, the researchers report that low-concurrency pairs (those working most independently of one another) were four times more productive than the potentially more collaborative high-concurrency pairs. That is, the reexamination of the existing data does not substantiate the productivity claims of the other studies. The authors then go onto propose that the difference might lie with the pair programming protocol itself, i.e. the pilot/navigator roles, and the switching between them that occurs during the development session.
Perhaps there is something within the pair programming protocol that would account for the productivity gains reported in the other studies mentioned by the authors. Then again, the difference may lie within the environments examined by the different researchers. One of the earlier studies looked into the productivity of experienced developers who participated in a short 45-minute pair programming exercise, while the other concerned itself with undergraduate Computer Science students who were paired during a semester. This latest study, however, was based upon data collected during a port of a legacy system which involved 3000 screens and a million lines of code. Without criticizing the earlier studies, you can still ask how well they translate to the real world.
So, the controversy remains unresolved. There are indeed studies that back up the claims of pair programmings proponents, especially in terms of higher code quality and programmer satisfaction/confidence. However, the jury is still out on the cost in productivity. It looks like conversations about extreme programming will continue to devolve into monologues.
A Field Study of Developer Pairs: Productivity Impacts and Implications, Allen Parrish, Randy Smith, David Hale, and Joanne Hale, IEEE Software, September/October 2004.
The Case for Collaborative Programming, John T. Nosek, Communications of the ACM, March 1998/Vol 41. No. 3.
Building Pair Programming Knowledge through a Family of Experiments, Laurie Williams, Charlie McDowell, Nachiappan Nagappan, Julian Fernald, and Linda Werner,
Proceedings of the 2003 International Symposium on Empirical Software Engineering.