done. We started at the bottom but found we had to work all the way to the top to be heard. There I learned there was only one concept that was really meaningful to IBM: BACK YOUR TRUCK UP. The fact of the matter was, IBM was in a new area too, which may be considered a plus factor in our case because, being innovators of the highest order themselves, they recognized that here was a new service problem. There were multitudes of users out of service, rather than just one.«
Buxton: The best method of feedback about unsatisfactory systems is money. If software had a clear monetary value a user could express his belief that the software was bad in clear monetary terms by rejecting it.
Galler: The typical user is not in a position to reject a major system produced by a large manufacturer.
6.5. DOCUMENTATION
There was much discussion of Design and Production aspects of documentation, but very little from the user’s point of view. The one working paper by Selig was concerned directly with this area. This paper is quoted below, and is the source of the set of document standards that are reprinted in section 9. That section also contains the paper by Llewelyn and Wickens, which touches on the reviewing of system documentation as part of acceptance testing.
Selig: (from Document for service and users)
»With the rapid proliferation of computer languages, subroutines and programs, and the tremendous effort they represent, meticulous documentation is becoming essential, not just to save money but to prevent chaos.
…
Reference manuals for the user, the operator and the programmer can be based on the external and internal specifications [of the system]. Such documentation … must be reader oriented and not subject oriented and good manuals are difficult to write. One common mistake is that authors try to reach too many different groups: managers, experienced technologists and beginners. It is recommended to develop different educational documentation with clearly defined prerequisites for the prospective readers.«
Letellier: (from The adequate testing and design of software packages)
»Manuals must be of two types: a general introduction to the solution of the problem by means of the package and a technical manual giving the exact available facilities and operation rules; these should be as attractive as possible. «
Gillette: The maintenance of documentation should be automated.
Selig: (from Documentation for service and users)
»It is appropriate to mention techniques where the computer itself is producing the required documentation with considerable sophistication. Especially flow-charting and block-diagramming are readily available. Examples of such programs are: Flow-chart plotting routine (CalComp), Autoflow (Applied Data Research), Com Chart (Compress), etc. A more efficient method of automated program documentation became available in the conversational mode of computer usage. A few software systems are now self-documented, and detailed information and instructions can be displayed at the operator’s request. The design of such programs is very similar to self-teaching manuals and this technique has become particularly well accepted in the area of computer graphics.«
Gries: The maintenance and distribution of the OS/360 documentation is automated through the use of a text-editing system. I don’t think the maintenance of this documentation would be possible without it.
6.6. REPROGRAMMING
The only material on the subject of reprogramming was the short working paper prepared during the conference by Babcock, which is reprinted below in its entirety. There was no direct discussion on the subject of the users’ problems in reprogramming for changed hardware or operating systems, but the sections of the Design area concerned with modularity and interfaces are of relevance.