»… Library programs should be designed to take as little as possible of the user’s time and offer him the greatest confidence in the results. When this requirement is satisfied the methods employed should be as economical of machine time as possible.
Because the various modes of operating (interactively and with fast or regular compilers) all have their special advantages, it is most useful to have the same language processed by all three methods. …
Operating systems should have scheduling algorithms that maintain the quality of service under changing user demands. In many instances as a system gets more heavily loaded, service to users deteriorates. The control of users’ demands by bad service is to be deplored.
Operating systems should be simple for the user. The default options, when leaving information unspecified in a control card, for instance, should always be the most commonly wanted ones. In time-sharing or multiprogrammed environments each user’s information should be assiduously protected. Nothing is more disconcerting than the possibility of interference from some other user. This is perhaps a greater concern than privacy of files.
An important part of any operating system is the accounting scheme. Assignment of charges to various parts of the computer resource-memory, processor time, disk space, etc., can influence the use made of these facilities. Any rationing schemes or assessing of prices should ensure that good user practice is encouraged. Since this costing is internal to the system it should aim to produce external minimal costs for the user-equipment system as a whole.«
d’Agapeyeff: (from Reducing the cost of software)
»Is one operating system per machine enough? Can an operating system within a single framework (although with many options) satisfactorily meet the needs of all classes of users (e.g. bureaus, universities, business batch processing, commercial online installations) or if not, how many different systems are likely to be necessary?«
Only a few remarks were directly concerned with the problems of quite specific designs, possibly because these problems are so numerous.
Kolence: (from On the interaction between software design techniques and software management problems)
»The definition of certain types of external characteristics may effectively dictate a basic internal design structure which results in unsatisfactory operational characteristics. Two opposing examples are useful to illustrate this point. In commercial data processing, the functions associated with a given run in a batch processing system may be so numerous that extremely tight coding is necessary to fit the program into core. In this instance, the evolutionary power of the program, (that is, the ability to modify the system,) will be severely limited. On the other hand, requirements to permit additional features or use of various input/output formats may be so extensive that a table driven design is dictated. This design type usually has slow operational speeds.«
4.2.3. RELIABILITY AND DESIGN
Reliability is one of the several issues that goes across the design-production distinction. Reference should therefore also be made to section 5.1.2. One remark specially mentioning design is given below.
Fraser: I just want to make the point that reliability really is a design issue, in the sense that unless you are conscious of the need for reliability throughout the design, you might as well give up.
4.2.4. LOGICAL COMPLETENESS
Logical completeness was put forward as an important design criterion. This gave rise to the following remarks.
Perlis: Logical completeness means that the system must be capable of performing at least a ‘basic’ set of operations before it can be classified as a system of certain kind. We are not interested in modest systems which do only half the job that one would ordinarily expect; that is too modest. I think that all of us agree that we could list a set of processes that we feel must be included in any language translator, without which we would not call