Quotes from the Nato Software Engineering Conference in 1968

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.

Related Posts:

  • Pingback: Beyond Fashions & Fads | The Agile Radar

  • Pingback: fiskeben.dk — » Softwareudvikling dengang

  • Dimitrs Daskalakis

    this creates a dizziness effect, similar to that when traveling back and forth in time.

  • Pingback: Monday Links from the Pub vol. CII

  • http://sebastianguenther.org/ Sebastian Günther

    Thanks for putting this together, it indeed still shows some of the weaknesses current software development techniques have.

  • Peter Krantz

    I find it interesting that they already had identified issues we still see today. In my experience some things have improved but much of it is still relevant. Should we focus more on the history of software development in CS education?

  • http://sebastianguenther.org/ Sebastian Günther

    A definite yes. I could imagine a course that has this form: An existing and complex software system is taken as a case study. Reports or protocols about design decisions and implementation choices are studied. Then students explain what they learned about the development approach. The students are presented with a list of known problems of this system, and are then asked to identify where the critical decisions that lead to these problems were made. This could very much help to educate future architects.

  • http://sebastianguenther.org/ Sebastian Günther

    A definite yes. I could imagine a course that has this form: An existing and complex software system is taken as a case study. Reports or protocols about design decisions and implementation choices are studied. Then students explain what they learned about the development approach. The students are presented with a list of known problems of this system, and are then asked to identify where the critical decisions that lead to these problems were made. This could very much help to educate future architects.

  • mamta soni

    your site is very informative and very usefull. thankyou 
    mlm software delhi

  • Pingback: 1968年北约软件工程大会语录 - KevinBlog

  • Pingback: My links of the week – October 6, 2013 | R4