Re-appropriating tools for Pair Programming: The Code and the IDE

As detailed in our 2006 publication*, pair programmers use many tools to assist their collaboration. In fact, even the code itself plays an important role in the pair’s communications. Rather than merely being the output or the driver’s ‘translation’ of the collaborative effort, both existing and work-in-progress code becomes a third contributor to the conversations between developers. It’s as if some of the value of the code when pairing is in it’s provision of an alternative form of interacting, in addition to speech, gesticulating and other physical communication cues.

For example, on many occasions during the 15,000 sentences of pair programming dialogue analysed, a period of silence did not indicate the end of an interaction. Rather, the conversation between the two programmers would trail off and the ‘talk’ would be continued by the driver typing at the keyboard. This was clearly the case where the developer not currently typing** interjected using agreement protocols normally reserved from conversations (e.g. Uttering “mmmmn” or “yes” or “uh huh”) as shown in the example below (as always a real conversation, but with names changed):

Alex:   “A slightly different side. That’s got a….(types code)

Beatrice: “Uh huh”


Beatrice: “Yeah, I think so. Yeah, it makes it easier to write accessor methods as well, I think. If you do….(types code)”

Alex:        “Yeah”

Beatrice: “OK, so that’s cool”.

The piece of code being referred to would often be pointed at (either with the mouse or a finger, or by highlighting with the cursor). In these cases, the distributed cognition obtained by using the code in this way often led to highly underspecified statements. These conversations are almost nonsensical without the code ‘joining in’. For example (where ‘this’ and ‘that’ are used to refer to parts of the code being pointed at):

Zac:         “Err……get this version of that… that’s got that… it’s come through there now.

Xandra: “So if you try and run that through there now”.

Zac:         “Is this a problem?”

Xandra:  “That should be included in the project”.

Zac:         “Yeah”.

Through these kinds of interactions it becomes clear that gesturing at the code allows the pair to incorporate it into their shared mental model. It would be interesting to investigate when and why the programming pair choose to interact via the code rather than in other modes. One could imagine that possible reasons would include disambiguation, tangibility and readiness of examples.

As well as this more passive role, one could even suggest that on occasions the IDE initiates a ‘conversation’, for example in the sessions recorded, when an automated test ‘went red’ this would trigger a conversation between the developers. Often this trigger would begin a whole new episode of problem solving.

* in collaboration with my fabulous supervisors Prof. Benedict Du Boulay and Pablo Romero and with kind funding from the EPSRC.

**often called the ‘navigator’ although I find this name a little misleading for reasons I will explain in later posts.


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