Thomas A. Alspaugh
Quotations (Software)

Annie Antón and Colin Potts

Stakeholders seldom understand their requirements fully at the beginning of a project. They often lack a clear vision of what the system should do and change their minds during development. In general, stakeholders only become more sure about what they want when they see a system that does not exhibit the necessary features.
p.157R¶1

The posing of systematic questions enables the derivation of a more complete set of goals and requirements.
p.162R¶1

The Use of Goals to Surface Requirements for Evolving Systems. In 20th International Conference on Software Engineering (ICSE 1998).

Barry Boehm

Clearly, it pays to invest effort in finding requirements errors early and correcting them in, say, 1 man-hour rather than waiting to find the error during operations and having to spend 100 man-hours correcting it.

Software engineering. IEEE Transactions on Computers 25(12):1126‑1241, 1976.

Frederick P. Brooks, Jr.

Oversimplifying outrageously, we state Brooks's Law:

Adding manpower to a late software project makes it later.

The Mythical Man-Month, 1975, p.25.

… [T]o see what rate of progress one can expect in software technology, let us examine the difficulties of that technology. Following Aristotle, I divide them into essence, the difficulties inherent in the nature of software, and accidents, those difficulties that today attend its production but are not inherent.
Does It Have to Be Hard?--Essential Difficulties ¶3

The most radical possible solution for constructing software is not to construct it at all.
Promising Attacks on the Conceptual Essence / Buy versus build ¶1

The hardest part of the software task is arriving at a complete and consistent specification, and much of the essence of building a program is in fact the debugging of the specification.
Hopes for the Silver / Program verification ¶4

The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.
Promising Attacks on the Conceptual Essence / Requirements refinement and rapid prototyping ¶4

No Silver Bullet: Essence and Accidents of Software Engineering. IEEE Computer, April 1987.

Computer science is like astronomy: best done at night.

From a class lecture.

Edsgar Dijkstra

Summarizing: as a slow-witted human being I have a very small head and I had better learn to live with it and to respect my limitations and give them full credit, rather than to try to ignore them, for the latter vain effort will be punished by failure.
p.3

Program testing can be used to show the presence of bugs, but never to show their absence!
p.7

Notes on structured programming, 1970.

C. A. R. Hoare

I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.

The Emperor's Old Clothes. 1980 Turing Award Lecture. Communications of the ACM 24(2):75-83, February 1981.

Michael Jackson

We all think Fred's brilliant … He swivelled round in his chair to face a huge flowchart stuck to the wall: about five large sheets of line printer paper, maybe two hundred symbols, hundreds of connecting lines. Fred did that. It's the build-up of gross pay for our weekly payroll. No one else except Fred understands it. His voice dropped to a reverent hush. Fred tells me that he's not sure he understands it himself.

… Jane came to us with a great reputation. We thought she was going to be as brilliant as Fred. But she hasn't really proved herself yet. We've given her a few problems that we thought were going to be really tough, but when she finished it turned out they weren't really difficult at all. Most of them turned out pretty simple.

Software Requirements and Specifications: A lexicon of practice, principles, and prejudice, 1995, Brilliance p.20.

Brian Kernighan and P. J. Plauger

Whenever possible we will build more complicated programs up from the simpler; whenever possible we will avoid building at all, by finding new uses for existing tools, singly or in combination. Our programs work together; their cumulative effect is much greater than you could get from a similar collection of programs that you couldn't easily connect.

Kernighan and Plauger, Software Tools, 1976, p.3.

Neil Maiden

Requirements engineering is asking the right question, of the right person, at the right time. Easy, isn't it?

Personal communication, 2004.

David L. Parnas

The major advancement in the area of modular programming has been the development of coding techniques and assemblers which (l) allow one module to be written with little knowledge of the code in another module, and (2) allow modules to be reassembled and replaced without reassembly of the whole system.
p.1053

Every module in the [information hiding] decomposition is characterized by its knowledge of a design decision which it hides from all others. Its interface or definition was chosen to reveal as little as possible about its inner workings.
p.1056

On the criteria to be used in decomposing systems into modules. Communications of the ACM, 15(12):1053-1058, 1972.

We view the documentation as being (at least) as important as the product itself: if there is good documentation, a software product can be revised or replaced relatively quickly; without good documentation, software products are of questionable long-term value.

Parnas and Madey. Functional documentation for computer systems. Science of Computer Programming 25(1):19-23, Oct. 1995.

I would advise students to pay more attention to the fundamental ideas rather than the latest technology. The technology will be out-of-date before they graduate. Fundamental ideas never get out of date. However, what worries me about what I just said is that some people would think of Turing machines and Gödel's theorem as fundamentals. I think those things are fundamental but they are also nearly irrelevant. I think there are fundamental design principles, for example structured programming principles, the good ideas in Object Oriented programming, etc.
What advice do you have for computer science/software engineering students? ¶2

(Q. What is the most often-overlooked risk in software engineering?)
Incompetent programmers. There are estimates that the number of programmers needed in the U.S. exceeds 200,000. This is entirely misleading. It is not a quantity problem; we have a quality problem. One bad programmer can easily create two new jobs a year. Hiring more bad programmers will just increase our perceived need for them. If we had more good programmers, and could easily identify them, we would need fewer, not more.
What is the most often-overlooked risk in software engineering? ¶1 (emphasis mine)

ACM Fellow Profile. Software Engineering Notes 24(3), May 1999.

flip bgunflip