Inspired by research on the role of affect in marital interactions, the authors examined whether affective interaction dynamics occurring within a 5-minute slice can predict pair programming performance. In a laboratory experiment with professional programmers, Group Hedonic Balance, a measure of the balance between positive and negative expressed affect, accounted for up to 35% of the variance in not only subjective but also objective pair programming performance. Implications include a new set of methods to study pair programming interactions and recommendations to improve pair programming performance.

This paper presents data from a four month ethnographic study of professional pair programmers from two software development teams. Contrary to the current conception of pair programmers, the pairs in this study did not hew to the separate roles of "driver" and "navigator". Instead, the observed programmers moved together through different phases of the task, considering and discussing issues at the same strategic "range " or level of abstraction and in largely the same role. This form of interaction was reinforced by frequent switches in keyboard control during pairing and the use of dual keyboards. The distribution of expertise among the members of a pair had a strong influence on the tenor of pair programming interaction. Keyboard control had a consistent secondary effect on decisionmaking within the pair. These findings have implications for software development managers and practitioners as well as for the design of software development tools.

This study explores interruption patterns among software developers who program in pairs versus those who program solo. Ethnographic observations indicate that interruption length, content, type, occurrence time, and interrupter and interruptee strategies differed markedly for radically collocated pair programmers versus the programmers who primarily worked alone. After presenting an analysis of 242 interruptions drawn from more than 40 hours of observation data, we discuss how team configuration and work setting influenced how and when developers handled interruptions. We then suggest ways that CSCW systems might better support pair programming and, more broadly, provide interruption-handling support for workers in knowledge-intensive occupations.