An alternative take on the ‘Driver’ and ‘Navigator’ roles in pair programming.

Our findings so far suggest that experienced pair programmers under-rate their experience. They also cast some doubt on previous claims about the nature of the ‘driver’ and ‘navigator’ roles, finding instead that:

  • Utterances about syntax and spelling are rare and not significantly made by one role or the other.
  • Both partners contribute new information equally to each of the sub-tasks in a pairing session (irrelevant of role).
  • Rather than working at different levels of abstraction, experienced pairs talk at many different levels, with no significant difference according to role.
  • Both roles speak significantly more at an intermediate level of abstraction (about chunks or areas of code) than at any other level.
  • Driver and navigator not only change role frequently, but do so in a very fluid manner with little or no explanatory conversation.

These findings imply that the navigator must continually maintain a firm grasp of what is happening during the session at a number of levels of abstraction, just as the driver must. As such, we suggest a different view of the driver and navigator roles.

1. The cognitive tag-team effect.

Given the frequency and fluidity in which experienced pairs change role, it is possible that one of the benefits of pairing is having a partner to help bear the additional physical and cognitive loads of both typing and providing (either externally or internally) a running commentary. The perils of multi-tasking are well known and documented. In fact, we suggest that the driver and navigator form a kind of ‘cognitive tag team’, working together, in synchrony, at the problem at hand and then switching role to alleviate the additional cognitive load that falls on the multi-tasking driver.

2. Intermediate level conversation as cognitive ‘glue’

It has been suggested that software developers need to be operating at several different levels of abstraction at the same time (e.g. Pennington, Lee and Rehder, 1995). For example: considering whether they are successfully solving the business problem at hand; ensuring that they are conforming to project coding standards; making good use of existing modules of code and ensuring that what they type is ‘grammatically correct’.

Finding that experienced pairs talk mostly at an intermediate level is interesting. It could well be that this kind of conversation is some form of mediating device that helps tame the complexity of considering many different levels of abstraction at once. In other words, perhaps such conversations provide the ‘glue’ that holds together the upper and lower levels of abstraction in order to help us successfully progress through an activity as complex as computer programming. In addition it may be that externalising our mental model verbally in this way helps us to objectify it and provides some much-needed additional cognitive ‘thinking space’.

This is the final post on my PhD findings. I have derived a set of ‘desirable’, ‘undesirable’ and ‘absent’ pair programming behaviours from this research (I am reluctant to call them ‘patterns’ or even ‘proto-patterns’ due to the stringent requirements of the Pattern community). If there is further interest I will aim to catalogue these in my next set of blog posts.

As always this post is written with thanks to my wonderful mentors and supervisors Prof. Benedict du Boulay and Dr. Pablo Romero of the University of Sussex and the funding from the EPSRC without which it would not have been possible.


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 )

Connecting to %s