Smith: There is a tendency that designers use fuzzy terms, like ‘elegant’ or ‘powerful’ or ‘flexible’. Designers do not describe how the design works, or the way it may be used, or the way it would operate. What is lacking is discipline, which is caused by people falling back on fuzzy concepts, instead of on some razors of Occam, which they can really use to make design decisions. Also designers don’t seem to realize what mental processes they go through when they design. Later they can neither explain, nor justify, nor even rationalize, the processes they used to build a particular system. I think that a few Occam’s razors floating around can lead to great simplifications in building software. Just the simple: how something will be used, can often really sharpen and simplify the design process. Similarly, if we use the criterion: it should be easy to explain, it is remarkable how simple the design process becomes. As soon as one tries to put into the system something that takes more than a paragraph or a line to explain, throw it out — it is not worth it. We have applied this to at least one system and it worked beautifully. As a result we had documentation at the same time as we had the system. Another beautiful razor is: the user should have no feeling that he is dealing with an inanimate object, rather he should feel that he is dealing with some responsive personality, who always responds in some reasonable way. Criteria like these have nothing to do with ‘powerful linguistic features’ or ‘flexibility’ and right at the beginning I think we should throw these fuzzy terms out of the window.
David: (in Some thoughts about production of large software systems)
»… experience… has led some people to have the opinion that any software systems that cannot be completed by some four or five people within a year can never be completed; that is, reach a satisfactory steady-state. While no one has stated this opinion as an immutable ‘law’, the question of what techniques can lead to a counter-example arises…
Define a subset of the system which is small enough to bring to an operational state within the ‘law’ mentioned above, then build on that subsystem. This strategy requires that the system be designed in modules which can be realized, tested, and modified independently, apart from conventions for intermodule communication.«
Gillette: (from Aids in the production of maintainable software)
»Three fundamental design concepts are essential to a maintainable system: modularity, specification, and generality. Modularity helps to isolate functional elements of the system. One module may be debugged, improved, or extended with minimal personnel interaction or system discontinuity. As important as modularity is specification. The key to production success of any modular construct is a rigid specification of the interfaces; the specification, as a side benefit, aids in the maintenance task by supplying the documentation necessary to train, understand, and provide maintenance. From this viewpoint, specification should encompass from the innermost primitive functions outward to the generalized functions such as a general file management system. Generality is essential to satisfy the requirement for extensibility.«
4.2.2. USER REQUIREMENTS
Several remarks were concerned with the influence of users upon the design.
Hume: One must be careful to avoid over-reacting to individual users. It is impossible to keep all of the users happy. You must identify and then concentrate on the requirements common to a majority of users, even if this means driving a few users with special requirements away. Particularly in a university environment you take certain liberties with people’s freedom in order to have the majority happy.
Babcock: In our experience the users are very brilliant people, especially if they are your customers and depend on you for their livelihood. We find that every design phase we go through we base strictly on the users’ reactions to the previous system. The users are the people who do our design, once we get started.
Berghuis: Users are interested in systems requirements and buy systems in that way. But that implies that they are able to say what they want. Most of the users aren’t able to. One of the greatest difficulties will be out of our field as soon as the users realize what kind of problems they have.
Smith: Many of the people who design software refer to users as ‘they’, ‘them’. They are some odd breed of cats living there in the outer world, knowing nothing, to whom nothing is owed. Most of the designers of manufacturers’ software are designing, I think, for their own benefit — they are literally playing games. They have no conception of validating their design before sending it out, or even evaluating the design in the light of potential use.