So what do the Driver and Navigator really do?

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.

You can view the full article (published in the International Journal of Human Computer Studies) here.



  1. This is great and I think there are other things to strive for than the two typical types of pair programming often written about: annoying back-seat driver (correcting the driver’s mistakes – who wants a person saying “whops, that’s the wrong gear”, “a little easy on the break now”, …) and low-level+high-level unpairing mode of working.
    I do have a question though, and that is what programming language(s) were used when the dialogues you’ve based your research on where recorded? Many high-level languages with a modern IDE will tell the driver when there’s a syntax or speling error. (You reference “Jensen, 2003; Williams and Kessler, 2000” which are 10+ years old and probably refer to a time where IDE:s and programming workstations weren’t as powerful as they are today. Thus, it’s not too strange that the way of working they prescribe in those books (including the “latency” of writing their books to begin with), it doesn’t match what we see in the field today.)

    1. Hi Fredrik,

      Thanks for the comment. I am sorry I didn’t make it clear in this week’s blog, however my research on this is nearly 10 years old too rather than “the field today”. I have started blogging it following some recent interest and people asking me to make it more accessible online. Hence the 2000 and 2003 claims I referenced were more historically relevant when the studies were done. That said, I still hear and read these claims all the time today (it drives me slightly crazy).

      Also, in 2003/2004 when I was doing the recording, modern IDEs were already very much in evidence. Most of the programming work was in Java. I remember being surprised at how much the IDEs did compared with when I was last a commercial programmer (up until 1999ish).

      Hope that makes sense and thanks again for the comment,


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s