Running away from a problem


late 1971 -- early 1972

Some former colleagues of Dijkstra have stressed in interviews with me that Dijkstra was not an engineer (in accordance with their definition of the term). By discussing Dijkstra's characteristic top-down design perspective in my previous post, I have already given one reason why Dijkstra was perceived as a non-engineer. Below I present another reason. While doing so we will again encounter the dichotomy between performance and generality, a dichotomy which Dijkstra seems to have stressed throughout his whole career.

Performance measures are of prime concern in several software niches. Examples are CPU utilization, execution time, storage fragmentation, and memory footprint. In Dijkstra's words:

In the design process it is not unusual that some sort of performance measure is dependent in a complicated and only partially known way on a design parameter whose value has to be chosen.

An example of a design parameter concerns the strategy of garbage collection. Choosing a garbage collection strategy influences storage fragmentation when the program at hand is executed. An increase in storage fragmentation can have an adverse effect on memory footprint. In summary, the value of a design parameter can influence several performance measures and choosing the optimal value is very difficult.

Dijkstra mentioned two usual but unsatisfactory approaches to the problem. The first is to assign a group the task of discovering the optimal value for the parameter. The second is to let the user of the system specify the value of the design parameter. The first approach leads to ``heated arguments and an overall paralysis of the design process''. The second approach doesn't help either because ``the user is equally unable to fix the parameter in a sensible way''. Instead, Dijkstra says, a competent designer should ``run away'' from the problem.

The most efficient way to solve a problem is still to run away from it if you can, and one can try to restructure a design in such a way that the parameter in question loses its significance. [my italics]

I am not able to give a specific example here. Can you? I suspect that the design of Dijkstra's earlier THE operating system contains several examples.

In any case, Dijkstra's urge to seek general solutions lay at the heart of his thoughts once again. Dijkstra stressed that such generalization often comes at the expense of application specific performance.

In individual applications the performance might be less than optimal, but this can be easily outweighed by greater adequacy over a wider range of applications and the easier justification of the remaining decisions.

Source: `EWD 317: On a Methodology of Design'.



Not an engineer?

When doing complex system design, "running away" as Dr. Dijkstra said is far from waving white flags. Don't you see Java hides all occurance of pointers from language user thus eliminates traditional C complexity and bugs dramatically. Some problems may be inevitable, not others. When one finds another way to make a problem irrelevant, GO FOR IT!

An "engineer"

I think your example about C and Java is very instructive.

Concerning the term ``engineer'': the fact that some former colleagues of Dijkstra did not consider him to be an engineer like themselves is not a matter of right or wrong. It merely hints at the possibility that these former colleagues had a research agenda that differed from Dijkstra's own agenda.