which to describe these general relationships in a concise, machine and language independent form would be of great value to the software industry by reducing design costs.
Lastly a requirement on notational form exists to permit the design description of a program to be used to define the checkout requirements of a system. Actually, this requirement is on both the external characteristic and the internal structure design notational forms. The problem of programming management, once the system is in the checkout states, are well known. A standard joke in the industry is that a program typically remains 90% debugged for about 25% of the total implementation time. A notational form, in conjunction with a greater understanding of the properties and structures of a program, is required to permit the program manager to properly monitor the progress of checkout.«
David: (from Some thoughts about the production of large software systems (2))
»Design Before Coding: The basic structure of the software, including modular divisions and interfaces, should be determined and documented before a coding begins. Specifications for modules and interfaces can be described in English, carefully phrased to avoid ambiguities.«
Gillette: One type of error we have to contend with is inconsistency of specifications. I think it is probably impossible to specify a system completely free of ambiguities, certainly so if we use a natural language, such as English. If we had decent specification languages, which were non-ambiguous, perhaps this source of error could be avoided.
Barton: Putting the integration of programming in machine organizations into the hands of one, or at most a few, people, gives an interesting opportunity to impose styles upon the workers under them. The old question of how do you implement programming systems, is it wise to use higher-level languages and so on, is often debated. I like to note that you can eliminate any need for debate in a working organization by imposing such a style through the initial system design. I have observed that people who have such a style imposed on them spend very little time objecting, it’s too late to object. Part of system design is the design of a style which will permeate down through the organization, however large. You can’t have anarchy down there, at least you have to restrict the area of anarchy.
Dijkstra: I have a point with respect to the fact that people are willing to write programs and fail to make the documentation afterwards. I had a student who was orally examined to show that he could program. He had to program a loop, and programmed the body of it and had to fill in the Boolean condition used to stop the repetition. I did not say a thing, and actually saw him, reading, following line by line with his finger, five times the whole interior part of his coding. Only then did he decide to fill in the Boolean condition — and made it wrong. Apparently the poor boy spent ten minutes to discover what was meant by what he had written down. I then covered up the whole thing and asked him, what was it supposed to do, and forced out of him a sentence describing what it had to do, regardless of how it had been worked out. When this formulation had been given, then one line of reasoning was sufficient to fill in the condition. The conclusion is that making the predocumentation at the proper moment, and using it, will improve the efficiency with which you construct your whole thing incredibly. One may wonder, if this is so obvious, why doesn’t it happen? I would suggest that the reason why many programmers experience the making of predocumentation as an additional burden, instead of a tool, is that whatever predocumentation he produces can never be used mechanically. Only if we provide him with more profitable means, preferably mechanical, for using predocumentation, only then will the spiritual barrier be crossed.
Perlis: The point that Dijkstra just made is an extremely important one, and will probably be one of the major advantages of conversational languages over non-conversational ones. However, there is another reason why people don’t do predocumentation: They don’t have a good language for it since we have no way of writing predicates describing the state of a computation.
The use of the computer itself to help in the documentation of the design was suggested many times, see particularly section 4.3.3 and 5.3.1. One other remark is given below.
Gillette: In the large, automation has not been exploited very well to aid in the communication process. Some experiments have been made, however. In developing the documentation for OS/360 the programmers had consoles in their offices and they could edit the texts with the aid of the computer. I have read some of the OS/360 docu