Sometimes we forget that other people have faced the same problems we face today in software development. These quotes are from the proceedings of the Nato Software Engineering conference in 1968.

On the management of software projects:

Programming management will continue to deserve its current poor reputation for cost and schedule effectiveness until such time as a more complete understanding of the program design process is achieved.

We build systems like the Wright brothers built airplanes — build the whole thing, push it off the cliff, let it crash, and start over again.

Production of large software has become a scare item for management. By reputation it is often an unprofitable morass, costly and unending. This reputation is perhaps deserved.

On the distinction between design and production:

Software production takes us from the result of the design to the program to be executed in the computer. The distinction between design and production is essentially a practical one, imposed by the need for a division of the labor. In fact, there is no essential difference between design and production […]

The most deadly thing in software is the concept, which almost universally seems to be followed, that you are going to specify what you are going to do, and then do it. And that is where most of our troubles come from.

On dealing with user requirements:

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.

We should have feedback from users early in the design process.

On programmer performance (compare with the essay Great Hackers by Paul Graham):

I have a question on the huge range of variability of programmer performance. Are similar ranges found in other engineering areas? [..] The variation range in programming is in fact greater than in other fields.

On the production of software:

We are starting gradually, and building up. My motto is ‘do something small, useful, now.

Large systems must evolve, and cannot be produced all at one time. You must have an initial small core system that works really well.

On testing software:

System testing should be automated as well. A collection of executable programs should be produced and maintained to exercise all parts of the system. […] As an output of a test validation run, each test should list the modules it has exercised, and as well, should list the interfaces and tables it has tested. It is important to document success, as well as failure.

and:

A software system can best be designed if the testing is interlaced with the designing instead of being used after the design.