If we look at popular descriptions of pair programming, we don’t have to search very far to come across ideas about how the behaviour of each partner differs according to role. The person at the keyboard is by convention the “driver” and the person not currently typing is commonly called the “navigator”.
Typically suggestions in the literature fall into two areas, some claiming both are present. I call these:
- Navigator as reviewer – Meaning that a significant part of the navigator role might include continually reviewing the work of the driver, pointing out spelling and syntax errors (e.g. Jensen, 2003; Williams and Kessler, 2000).
- Navigator as foreman – Suggesting that the driver works at lower levels of abstraction, typing in code and doing other tactical work while the navigator is working more strategically at the higher levels, sitting back and considering how the system fits together as a whole and relates to the business domain. I use ‘foreman’ in the absence of a better metaphor, thinking of the foreman as concerning himself with how the whole building is fitting together, rather than how each brick is laid. (Example claims include Dick & Zarnett, 2002 and Hazaan & Dubinsky, 2003).
Both of these concepts concern ‘levels of abstraction’ in the broader sense that distinguishes both level of granularity in the programming domain and delineates between the programming and the problem (or real world) domain.
In order to further explore these claims I analysed the dialogue of experienced pair programmers. I coded 14,866 sentences of pair conversation according to the level of abstraction of each utterance. I based my codings on Pennington (1987) with the addition of BRIDGE (from Good and Brna, 2004) for use when utterances bridged or connected the real / problem domain and the programming domain.
Overall there was significantly more discussion at a kind of intermediate level irrelevant of role. The pairs talked about blocks of code (in which I include tests and abstract coding concepts), like “that loop”, “the error handling”, “this database table”.
In general terms, the two roles did not significantly talk more or less than one another either. In addition, the navigators observed did not talk more or less at any particular level of abstraction than the driver.
Navigator as reviewer: The average number of syntax and spelling related utterances per session was a mere 14 of an average total of 620. Moreover, these rare remarks were evenly distributed between driver and navigator across all of the sessions in which they occurred. This suggests that, while useful, reviewing and correcting syntax and spelling is not core to the usefulness of the navigator role.
Navigator as foreman: The pair programmers in the sessions observed did not show the navigator working at a generally higher level of abstraction than the driver. Rather the pattern of abstraction levels of navigator’s utterances are very similar to those of the driver and do not differ significantly.
This poses two questions: First, if driver and navigator roles cannot be defined by continual review or levels of abstraction, then how might they contribute to the production of higher quality software? Second, why do the driver and navigator speak significantly more at the intermediate level?
Next post I will suggest an alternative view of the interaction of driver and navigator.