

Quotes from the NATO Software Engineering Conference in 1968 - pkz
http://www.peterkrantz.com/2011/software-engineering-in-1968/

======
pnathan
I've done some diving down into other 50s/60s papers, and after a while you
get a sense of "New Software Methods, Same As The Old". Fundamentals of
software engineering have not changed since the 60s, but languages and problem
contexts have.

It's a great experience reading on the old hackers, really gives you a sense
of context.

~~~
yassim
Any links you can share please? I love coming up with new ideas, only to find
out that it has all been done well before my time.

~~~
pnathan
My research is in debuggers, so the refs are debuggery.

The Diagnosis of Mistakes in Programmes on the EDSAC, in my opinion, _the_
classic software engineering paper. It was written in '51 or so. Pretty much
every major technique in debugging was invented then except for the proof
checking that started to come out in the '80s.
<http://sal.cs.bris.ac.uk/~dave/gill.pdf>

The history of early PDP debuggers is fascinating. Look up FLIT and DDT for
the TX-0/1 and the PDP-1.

Also take a look at Balzer's EXDAMS paper from AFIPS '69.

Evans and Darley had an interesting survey as well in AFIPS '66.

Production of Large Computer Programs by Benington describes a really nice
simulator (early 50s).

Backus invented an interpreter and described it in "The IBM 701 Speedcoding
system". [http://www.cs.virginia.edu/~cs415/reading/backus-
speedcoding...](http://www.cs.virginia.edu/~cs415/reading/backus-
speedcoding.pdf)

The guy over at Bitsavers has some old works there:
<http://www.bitsavers.org/pdf/mit/tx-0/memos/_MemoIndex.txt>

A few gems that I've found and I think these references will supply: Lisp had
amazing debugging capabilities in the mid-60s. Fully comparable to Visual
Studio 2005 IMO. In the same timeframe, Fortran had an interpreter (aka
QUIKTRAN iirc) that would provide analysis and code coverage stats.

I have had enormous issues digging up any information about the 50s corporate
computer capabilities; most of the information I have been able to find is
related to MIT computer work. As sort of a personal commentary, I've slewed
hard towards open-source because of lack of decent corporate records from this
period. If we don't open source our work, how will later generations build on
it?

If you want my bibliography, send me an email and I'll give you a copy.

------
cafard
As somebody (Jon Bentley? Gerald Weinberg?) says he was corrected, this was in
fact very much not the way the Wright brothers worked. They had no degrees but
they were very careful engineers.

------
lifeisstillgood
The main point to me is we still insist on this being engineering as opposed
to creative writing.

No-one sets out the specifications for a novel, or even a marketing report.

~~~
nialo
Marketing reports and novels have specifications just as real as any physical
engineering project, you're just required to guess at what exactly they are.

Whatever you're making, there's going to be some set of things that it must
accomplish. It's much easier to make the correct thing if you know what those
are in advance. The fact that acquiring specifications is hard, or that users
don't actually know what they want doesn't change the fact that you want as
precise a spec as you can get.

~~~
fooandbarify
Often there are multiple options for what the thing you are making must
accomplish (though some may be more valuable than others). I have found this
fact liberating with regards to novel writing in particular, a case in which I
personally would abhor a precise spec.

I do generally prefer very precise specs for engineering projects, of course.

------
pagekalisedown
The quotes under "On the production of software" remind me of Unix, which came
soon after.

