Experiences of Using Pair Programming in an Agile Project
Reviewed by Jorge Aranda / 2011-10-11
Keywords: Agile Development, Pair Programming
Vanhanen2007 Jari Vanhanen and Harri Korpi: "Experiences of Using Pair Programming in an Agile Project". 2007 40th Annual Hawaii International Conference on System Sciences (HICSS'07), 10.1109/hicss.2007.218.
The interest in pair programming (PP) has increased recently, e.g. by the popularization of agile software development. However, many practicalities of PP are poorly understood. We present experiences of using PP extensively in an industrial project. The fact that the team had a limited number of high-end workstations forced it in a positive way to quick deployment and rigorous use of PP. The developers liked PP and learned it easily. Initially, the pairs were not rotated frequently but adopting daily, random rotation improved the situation. Frequent rotation seemed to improve knowledge transfer. The driver/navigator roles were switched seldom, but still the partners communicated actively. The navigator rarely spotted defects during coding, but the released code contained almost no defects. Test-driven development and design in pairs possibly decreased defects. The developers considered that PP improved quality and knowledge transfer, and was better suited for complex tasks than for easy tasks.
As with many other practices, one of the great challenges of studying pair programming is that running experiments under controlled conditions in the lab eliminates many of the factors that are supposed to make it work. Pair programming works best, the argument goes, if the programmers are familiar with the dynamic and with each other, and some of its benefits (such as better knowledge transfer and team morale) only become apparent after continued use.
It's no surprise, then, that some of the best controlled experiments on pair programming that we have show poor productivity numbers in comparison to solo programming. But researchers have also studied pair programming as it actually happens in real projects, and although the emerging picture is still not entirely clear, it is more favorable to pair programming than lab experiments would have it. An example is this paper by Vanhanen and Korpi, who report on the consequences of extensive use of the practice. With respect to productivity, they found that pair programming was better for complex tasks, though no match for solo programming on easy tasks. Other factors (quality, morale, knowledge sharing) were largely positive.