The social dynamics of pair programming

Reviewed by Jorge Aranda / 2011-07-11
Keywords: Pair Programming

Chong2007 Jan Chong and Tom Hurlbutt: "The Social Dynamics of Pair Programming". 29th International Conference on Software Engineering (ICSE'07), 10.1109/icse.2007.87.

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 decision-making within the pair. These findings have implications for software development managers and practitioners as well as for the design of software development tools.

The myth of the driver/navigator split in pair programming is very pervasive: I've found it in almost all descriptions of pair programming I've seen, and in the language that programming pairs use to refer to the work that they do. However, Chong and Hurlbutt report that, effectively, programming pairs perform the same mixed role throughout their collaboration. They also have some interesting observations on the effect of keyboard control and expertise differentials within the pair.

Their suggested implications for pair programming (discussed in Section 6):

  • Move beyond the "driver" and the "navigator". This artificial role distinction only muddles the learning process of a new practice.
  • Help programmers stay focused and engaged. The authors suggest this can be achieved with good hardware support (hardware that supports, for instance, fast keyboard switching between pairs).
  • Consider differentials in programmer knowledge. Too great a difference is not productive.
  • Avoid pair rotation late in a task. Re-pair based on task completion, not on day cycles.

The latter two suggestions seem commonplace in the firms that I've observed that do some pair programming, but I've found that the former two still need wider dissemination. What is your experience?