it such. Designing perfect, but incomplete, systems is probably worse than designing somewhat unreliable, but complete, systems.
Genuys: I would like to know what exactly you mean by logical completeness.
Randell: We certainly don’t have a complete answer. It is just that you will sometimes see a system that is obviously not logically complete; that can, for instance, produce tapes that it cannot read back.
Ross: The idea is the mathematicians’ concept of closure, of a group for example, where for every operation you have an inverse operation. It is that idea iterated many times in all parts of the system.
Perlis: Another example: building an assembly system in which the routines that are assembled cannot be entered into the library, except by a totally separate set of actions and tasks, and possibly recoding and so forth.
Genuys: I think I would just prefer another term because this one has a certain logical flavor, and I am not certain that …
Perlis: [Interrupting] The word ‘logical’ has a meaning outside the realm of logic, just as the word ‘complete’ does. I refuse to abrogate to the specialist in mathematics the word ‘completeness’ and in logic, the word ‘logical’.
Bauer: The concept seems to be clear by now. It has been defined several times by examples of what it is not.
4.3. DESIGN STRATEGIES AND TECHNIQUES
4.3.1. SEQUENCING THE DESIGN PROCESS
The problem of the proper order in which to do things during design is currently a subject for research in software engineering. This was reflected in the extensive discussions during the conference.
Naur: In the design of automobiles, the knowledge that you can design the motor more or less independently of the wheels is an important insight, an important part of an automobile designer’s trade. In our field, if there are a few specific things to be produced, such as compilers, assemblers, monitors, and a few more, then it would be very important to decide what are their parts and what is the proper sequence of deciding on their parts. That is really the essential thing, what should you decide first. The approach suggested by Christopher Alexander in his book: Notes on the Synthesis of Form, is to make a tree structure of the decisions, so that you start by considering together those decisions that hang most closely together, and develop components that are sub-systems of your final design. Then you move up one step and combine them into larger units, always based on insight, of some kind, as to which design decisions are related to one another and which ones are not strongly related. I would consider this a very promising approach.
David: (from Some thoughts about the production of large software systems (2))
»Begin with skeletal coding: Rather than aiming at finished code, the first coding steps should be aimed at exploring interfaces, sizes of critical modules, complexity, and adequacy of the modules […]. Some critical items should be checked out, preferably on the hardware if it is available. If it is not, simulation is an alternative. The contributions of this step should be insight and experience, with the aim of exploring feasibility.«
Kolence: (from On the interaction between software design techniques and management problems)
»Consider how the understanding of the types of structures and relationships that exist in a software product affect the manager’s decision on how to begin the development of a design, by establishing the initial design specifications. The most important concepts which must be available to him are those of external product characteristics and internal program design. A set of specifications must be developed on the external features of a product but at the same time, these features must be properly related to the internal design structure of the program to be produced. Unless this relationship is understood, and made explicit, the manager runs the risk of becoming committed to the development of minor external features which may be disproportionately expensive to implement by the desired internal design.
…