Abstract
Considering that pair programming has been extensively studied for more than a decade, it can seem quite surprising that there is such a lack of consensus on both its best use and its benefits. We argue that pair programming is not a replacement of usual developer interactions, but rather a formalization and enhancement of naturally occurring interactions. Consequently, we study and classify a broader range of developer interactions, evaluating them for type, purpose and patterns of occurrence, with the aim to identify situations in which pair programming is likely to be truly needed and thus most beneficial. We study the concrete pair programming practices in both academic and industrial settings. All interactions between teammates were recorded as backup behavior activities. In each of these two projects, developers were free to interact when needed. All team interactions were self-recorded by the teammates. The analysis of the interaction tokens shows two salient features: solo work is an important component of teamwork and team interactions have two main purposes, namely cooperation and collaboration. Cooperative backup behavior occurs when a developer provides help to a teammate. Collaborative backup behavior occurs when the teammates are sharing the same goal toward solving an issue. We found that collaborative backup behavior, which occurred much less often, is close to the formal definition of pair programming. This study suggests that mandatory pair programming may be less efficient in organizations where solo work could be done and when some interactions are for cooperative activities. Based on these results, we discussed the potential implications concerning the best use of pair programming in practice, a more effective evaluation of its use, its potential benefits and emerging directions of future research.