Nearly all of the experienced pair programmers I studied put something down on paper. In more than three quarters of cases this was a highly informal (verging on illegible) sketch
Sometimes a more formal, communal diagram or model already existed, but the pair still preferred to create something of their own. When pressed they agreed “if it’s pre-drawn you feel like there’s nothing you can contribute” or “(this) feels more comfortable than an official document”. It brings to mind the maths teacher point of view that it’s nice to use chalk on a blackboard because the picture emerges slowly and the calculations can be understood bit by bit.
The extent to which the non-sketching partner engaged with the sketch varied widely. In fact, it was often hard to tell whether the sketch was for collaborative or individual use. For example, the representations sometimes seemed to be used to clarify the thoughts of the sketcher. In one extreme example the ‘sketch’ was merely traced on the table with a finger. “It’s like a brain-dump” said one developer. “If I scribble it down I can find out if I’m thinking absolute rubbish”, explained another. It is possible these sketches were used as part of the pragmatics of the interaction (for emphasis, say). Alternatively (and I feel intuitively that this is more likely) their role may be to lower the load on working memory and assist the developer in discovering inferences (see Tversky, 2002) or to attempt to work externally with very rich, multi-dimensional models (discussed in my previous post Who says programming isn’t creative?). Perhaps sometimes more of a personal thinking tool than a means of explanation.
Often the sketches highlighted structure or logic regarding how things related to each other. In one session, a timeline was drawn to show the relationship between three conceptual dates and in another a diagram was produced to show how one method called a number of sub-routines. “It helps communication better than just talking” agreed one pair, “some things are hard to articulate…so it gives you a common..language” said a developer. Below is an excerpt of an actual conversation (as always, not their real names):
Stuart: Oh god (laughs)….Shall we just draw the hierarchy?
Stuart: Because it’s….it’s more than just one.
Tine: It’s loads, isn’t it?
The perceived usefulness of these sketches was interesting too. When I asked, I was told that in most cases “between a pair it’s easier to just whack out a piece of code” or “you work in small mini-steps, so you can keep it all in your head”.
More formal, communal representations were present on every single project. Either posted up in some physical project space or on the intranet, their role seemed more general / holistic. They seemed to exist to allow the wider implications of a pair’s work to be visible, to provide a means of facilitating communication across pairs and to ensure an understanding of the system as a whole.
Next time: Making lists.