With respect to the tackling of an incompletely specified problem, even if your problem is completely specified, the first thing you do is forget about some of the specifications and bring them in later on. It does not in fact make very much difference whether the problem you have to solve is completely specified or not, provided the specifications are not conflicting when the task to be done is subject to alteration. It only means that the things left open will be readily answered in the case of the completely specified one. In a sense, treating the completely specified problem is more difficult because then you have to decide for yourselves which of the aspects of the problem statement you can allow yourselves to forget for the time being. If you have a completely specified problem it means that in the earlier stages of analysis you have to find yourself the useful generalisation of the problem statements. Whereas, if you have an incompletely specified problem you have to solve a class of problems and you start with given class and that’s easier.
Randell: Though I have a very great liking for what Dijkstra has done, as usual part of this is because of how he has explained it and part of it is in spite of how he has explained it. There’s one particular example I would like to give of this. The word ‘proof’ causes me to have a sort of mental hiccough each time he uses it. Whenever I try to explain his work to somebody else I say ‘satisfy oneself as to the logical correctness of’.
Paul: What is a proof about an algorithm?
McIlroy: A proof is something that convinces other mathematicians.
Perlis: I think that we have gotten switched off the main track, in that Dijkstra’s paper has another point besides the idyllic one of proof, and that is that there is also a design process described in the paper. He may have designed that process to make proof easy but I regard that as putting the cart, as it were, before the horse. The design process was organised as a view of constructing a complex system, which is that of building a layering of virtual machines, the organisation being that at one layer something is a variable which at another layer becomes a constant, one layer or many layers below it, and this is the way he chose to design the system. Now that design process is, I think, independently valuable whether you prove anything or not.
4.3.3. FEEDBACK THROUGH MONITORING AND SIMULATION
The use of feedback from a partly designed system to help in design, was discussed at length. The center of interest was the use of simulation during design. This subject was introduced in the working paper: B. Randell: ‘Towards a methodology of computer systems design,’ reproduced in section 9. This paper gave rise to an extended discussion.
Barton: What Randell is doing is also being done by a small organization in a production environment that can’t afford research, and the approach seems to work.
Perlis: The critical point is that the simulation becomes the system.
McIlroy: I would have much more faith in a manager’s statement: ‘The system is two weeks from completion’ if he had used this technique.
Bauer: But one should be careful not to use wrong parameters during the simulation.
Graham: The important point in Randell’s paper is the use of simulation. To-day we tend to go on for years, with tremendous investments, to find that the system, which was not well understood to start with, does not work as anticipated. We work like the Wright brothers built airplanes: build the whole thing, push it off the cliff, let it crash, and start over again. Simulation is a way to do trial and error experiments. If the system is simulated at each level of design, errors can be found and the performance checked at an early stage. To do simulation we should use a high level language and the standard simulation techniques, with the steps:
1) describe functions
2) describe data structures
3) describe as much of the model as you know, guess at the rest; the language will need primitives for description of high-level elements;
4) describe input/output patterns