Vertical debugging considers addresses the problems the model has, within its scope. The phenomena in this section are those which are incorrectly predicted by the model.
4 . 2 . 1 . Task switching
In the previous chapter, the execution element of the model was based around an MS- Windows analogy. Two main properties of Windows were recruited. Firstly the object metaphor, with its encapsulation of data and procedures, and secondly its non- preemptive multitasking mechanism.
It was also stated in the previous chapter that one of the potential problems with the model as it stood was the inelegant interruption mechanism. This can now be
elaborated upon, in the light of this first set of observational data. Interruption is one instance of the general class of task switches. Such behaviour has now been
observed, and it is thought that the data in the form of verbal protocol statements do not provide the necessary (low) level of description.
To justify a non-preemptive scheme, it would be necessary to specify at least some of the messages upon which it is based and so capitalise on the particular features of such a system over any other. One of the properties of a non-preemptive system is that tasks can only be switched between the processing of two messages. Turning this round, it means that messages must specify behaviour at the level at which task switching occurs. To give an example, if it were observed in one of the above tasks that subjects always finished everything to do with washing the potatoes before moving on to cleaning the fish, and then finished cleaning the fish before moving on again, then there would only need to be messages of the order of clean the fish and
wash the potatoes. Instead, it is observed that task switches occur much more often, in the middle of tasks described at such a (relatively) high level. To persist with the message mechanism, it would be necessary to be able to describe tasks at a much lower level, probably almost in terms of actions, at a level where it can be considered to be atomic. It is not possible to support this using the verbal protocol data.
In terms of the developmental strategy (Chapter 2), this is included as an example of Debugging in Vertical Development, since it is obviously a deficiency in the model, but is thought to be generally within its scope.
4 . 2 . 2 . Scheduling is Imperfect
In the model, each stream of activity is conceived as a separate entity - a Task Unit structure, which has the potential to complete that task independent of the other tasks. It is the central controlling structures and the schedule that are thought of as providing the multitask context for the individual tasks. There is evidence to suggest that this is the case. For example, take the task of cooking a vegetable such as mangetout. This could be broken down into the sequence of activities “Wash & Chop” then “Boil for five minutes”. If one were doing this task on its own, then there would be no reason not to boil them as soon as they had been washed and chopped. However, in a multitask context this might not be the best thing to do and might result in the task being completed too early. This is illustrated in the following protocol examples. S8 [Has just finished scrubbing his potatoes:]
“Right, so I'm turning the spuds on at a quarter to 7, they should take about 20 minutes, so targetting about 5 past 7 - But I’ll leave them for a bit because the oven still isn't hot enough - it’s taking a long time, isn't it? ... OK, well the spuds I reckon should take about 20 minutes so, yes, so I'll hang fire on the spuds for a bit”
5 7 2 2 3 And it’s about a minute past 7, so I probably ought to turn the carrots down again,
having just turned them up. (Are they boiling?) They're not boiling yet, no, but I ______ want to slow them down now, because I haven't started cooking the fish yet”_____
Whereas the above illustrate the imperfect nature of the schedule with respect to timing, the same is true of resource allocation. Resources are items, tools for example, that are required by the person for some period of a task, after which they may be used in a different task. In the example of cooking, resources might include saucepans and stove rings.
S8 “Put that on a low heat (Is there any reason why you chose to use that back ring for doing the sauce?) Yes, I mean its a kind of lowish - that's kind of not as strong as these ones, so, I mean its only a sauce, so it doesn't need to be fiercely heated, so I’m using this one because it doesn’t matter if its not very strong.”______________ However, had he objectively considered all the variables, he could have avoided the particular consequence:
S8 “Its a bit silly doing it on the back, because you’ve got the steaming potatoes in front of you.”__________________________________________________________ In a similar vein, when choosing which of the three saucepans to use in a particular task, S9 makes a reasoned decision:
S9 “I should have used the other saucepan, I’ll have this for the mangetout. I’m not being very clever here. OK, (Why are you going to do that?) Because its better to use the little one for the smaller quantity"** _________________________________ However, this decision fails to take the other tasks into consideration, with the following consequence:
S9 “the cheese sauce. Ah now, what I've done is I've used - 1 would have liked to have kept this saucepan for the cheese sauce, quite frankly, because its more manageable to keep lifting on and off the heat”______________________________ - the result is that she takes the water heating for the mangetout out of the smallest pan and uses this pan for the cheese sauce.