Browse Prior Art Database

Anecdotes: Remembrances of a Graduate Student Disclosure Number: IPCOM000129600D
Original Publication Date: 1988-Mar-31
Included in the Prior Art Database: 2005-Oct-06
Document File: 3 page(s) / 18K

Publishing Venue

Software Patent Institute

Related People

Mary Shaw: AUTHOR [+2]


Carnegie Mellon University Pittsburgh, PA

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 42% of the total text.

Page 1 of 3


Copyright ©; 1989 by the American Federation of Information Processing Societies, Inc. Used with permission.

Anecdotes: Remembrances of a Graduate Student

Mary Shaw

Carnegie Mellon University Pittsburgh, PA

Just as some years are memorable for their wines, some years are memorable for their research. In software, 1968 was such a year. It was the year the software research community really started thinking systematically, even formally, about software structures.

I don't think we at Carnegie Mellon were especially aware that Al Perlis had gone to Garmisch, but when the proceedings came out early in 1969 he got a box of them and dispensed them to the graduate students: "Here, read this. It will change your life."

Elsewhere in 1968, Dijkstra published the GOTO letter, we got our first copies of Knuth's Volume 1, and we were just catching on that Floyd was serious about making formal assertions about programs. We argued strenuously about whether the GOTO disciplines were too restrictive: why shouldn't we use GOTOs? Avoiding them makes programs look contorted. We loved Knuth: here were the tricks of the trade, all collected in one place, discussed, compared, analyzed. We were fascinated by the possibility that you could know the outcome of a running a program, rather than just believing (or, more likely, hoping).

The NATO conference proceedings arrived in that setting. The title captured our imagination. Why shouldn't software be a product, subject to analysis, prediction, and organized development? My copy of the proceedings still has markers in it. Here are some of the issues they flag:

[Naur p. 45]: Importance of decomposable designs. "It would be very important to decide what are their parts and what is the proper sequence of deciding on their parts." Here also is an early pointer to Alexander's Notes on the Synthesis of Form.

[Opler and Perlis, p. 72]: Need for quantifying our notions of reliability. Opler: "How many errors should we be prepared to accept in a system containing one million instructions?" Perlis: "Seven."

[Opler, p. 100]: Significance and difficulty of performance measurement. You must provide resources for performance evaluation during development and feedback at the same time. A warning: "it is fatally easy to concern oneself with only those quantities which are easy to measure, and to ignore other, possibly more important, quantities whose measurement is more difficult."

[Randell, Koehler, and Gillette, pp. 110-111]. Dominance of maintenance in the life of a software system. Randell noted that corrections and extensions are not distinguished; Koehler argued that maintainers ought to set the criteria for testing; Gillette pointed out that maintenance costs often exceed original development costs.

[McIlroy, Perlis, d'Agapeyeff, Endres, Naur, pp. 150-153]: Difficulty of software reuse. A component industry is needed, but it will be very hard to standar...