Handling in Context

The handling process is managed by how Marcus and Joe assess situations, the information they draw upon, and the mechanisms they try. Attention is often commanded because conditions are unexpected or new, but a situation can turn out to be familiar. Subsequent handling may draw upon knowledge gained through previous experience. The following exchange drawn from Episode 2, and provided in full in Appendix C.3.2, demonstrates both perspectives:

Marcus: Now this is something to do, I had to solve this recently and I can't

remember how I did it.

Joe: It's an import, you need to import it, don't you? Or it needs to be umm, oh

wait, its trying to execute that as a--

Marcus: --It’s the, the look. There's a, I did this before. It's to do with the way it

does the test running stuff. Let's just have a quick look [Driver opens Eclipse] in examples that we were messing about with hums. (Ep. 2, 00:20:43)

Guessing is a prominent feature of the incidents in this dataset. Guesses are informal and pervasive. They are both right and wrong, often made solely in response to perceived effects. Joe responded to the error message by making three swift guesses about what was wrong. Later in the exchange, he takes a fourth stab about which configuration file will contain the information. All of the guesses Joe makes in this incident turn out to be incorrect. They are an indicator of novelty, and suggest that Joe has encountered a problem that will require conscious problem solving.

Sometimes guessing is used to propose tactics or mechanisms that have an information- al basis. In the exchange given above, Marcus takes an informed guess to look at configu- ration files within the IDE. The handling process he follows demonstrates that knowledge drawn from prior experience is often of limited utility. The environment does not always effectively guide problem solving. In this incident, configuration files are located in different parts of the JAVA project filesystem and they all have the same name. Marcus knows he needs to look in one of the files, but he does not know which file will contain the information. He takes guesses about which files to open and examine. The identification of a solution, as in this case, is often also perceptual. Marcus had to open and look at several files before recognising information in one that he perceived was correct (“That's the one I wanted”).

Errors may be encountered together, but they are handled individually. One member of the pair may indicate that a problem is new, while the other may indicate that it is familiar. In this incident, Marcus was able to identify behaviour in the software that the configura- tion manages, but he didn’t explain exactly what the configuration does. Joe’s experience was new. His understanding formed by watching how Marcus handled the problem: the actions he took in the development environment and the connection he mades between information stored in the development environment and the wiki.

Likewise, the two do not always notice that something has gone wrong at the same moment, or attribute the same significance to system responses or behaviour in the software. Information is often freely given, but not received: the developer at the desk may not respond to suggestions given about actions to take or warnings about problems. At times, each developer appears to privilege behaviour in the environment over what he is told, only making a detection once he can assess effects. Thus the same error may be

Differences in rates of understanding are not necessarily evidence of differences in reasoning skill or expertise. They serve informational purposes in paired work. Dialogue and commentary are important sources of feedback. Comments can focus a partner’s attention, correct an assessment, or trigger an evaluation. The act of explaining a choice triggered detection in one case. Evidence was also given that pairs guide each other on occasion, dictating changes to be made in the code. The steps in these cases are not intended to produce a recovery for the error. Instead, they are given to stabilize the process, restoring immediate behavior so that problem solving can continue.

6.3.5 Modulators

Questioning is prominent in the incidents, found in the context of guessing, but also of other modulators like doubt and blame. Marcus and Joe ask questions when they are not able to make sense of a situation. They question the behaviour of the software (“What is going on?”), the stability of the environment (“What has changed?”), and the location of resources (“Where is it?”). They are doubtful about actions they have taken (“Oh that was the wrong page, wasn't it?”) and about where the source of the problem might be (“I wonder if it’s like, no?”).

Blame is used to deflect responsibility (“That's nothing to do with us.”), and to probe for information about a potential source of the error (“What have you done?”). Blame often targets limitations of the environment. In this sense, it functions as an invocation of an external constraint (Guindon et al., 1987), allowing the developers to set boundaries on responsibility. As noted by Eisenstadt (1997), blame is sometimes misdirected, but in this dataset, it appears more often to be a feature of setting boundaries for investigative activities. In these videos, the laptop on which work is being performed is commonly used in this way.

Blame may be associated with knowledge transfer between developers. Throughout the episodes, the pair is working on Marcus’ machine, and there is some evidence to suggest that in between episodes, development software is installed and updated by Joe. Given this context, blame may be placed in order to draw out information about the work that was performed, particularly when there is evidence to suggest that it may have a role to play in something that has gone wrong.

Emotive statements like doubt, blame and questioning are sometimes indicators that the developers have entered a “turbulent area” (Amalberti, 2001, p. 119). Within exchanges that are not stable, such statements are recognisable because they are often partially articulated and do not indicate directed reasoning. An example of a severe incident with evidence of blame can be read in Appendix C.3.3. Severe incidents begin like other error handling processes. Marcus and Joe use established tactics and mechanisms, for example by gathering information, or verifying that they are looking at the right page in the web browser. They also manipulate the environment, doing things like flushing caches, stopping and starting a web server or reloading web pages. However in severe handling instances, these techniques do not work.

The severity of issues is linked not to the amount of time an issue takes or the number of tries, but to how “in control” the developers perceive themselves to be. In the most severe incident in the catalogue, Marcus and Joe encountered an incident two thirds of the way through a filmed episode. The issue took over the remainder of the episode, and was not resolved in the whole of the next film, captured on the same day. In total, some 50 minutes of filmed time were spent in problem solving to identify what was wrong.

In this incident, problem solving efforts progressed from very simple examination of files, to discussion about design commitments, and consideration of prior work that used

incremental unexpected outcomes produced during local problem solving, that they resorted to adding a println() statements to code that would appear in output. Their level of stress and doubt were high, one of them remarking that such tactics were needed to allow them to “prove” that the basic “laws of programming” were intact.

In fact, the very first guess that the developers made about the source of the error brushed up against what went wrong: the framework has a dependency on a jar file that is placed at runtime into the filesystem. The developers were aware of this, and checked to see that it was in place. They failed to notice, however, that they checked for the existence of the file in the wrong place.