Quotes from the NATO Software Engineering Conference in 1968(peterkrantz.com)
peterkrantz.com
Quotes from the NATO Software Engineering Conference in 1968
http://www.peterkrantz.com/2011/software-engineering-in-1968/
4 comments
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.
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...
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.
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...
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.
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.
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.
No-one sets out the specifications for a novel, or even a marketing report.
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.
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.
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.
I do generally prefer very precise specs for engineering projects, of course.
The quotes under "On the production of software" remind me of Unix, which came soon after.
It's a great experience reading on the old hackers, really gives you a sense of context.