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.
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).
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.
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.
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.
It's a great experience reading on the old hackers, really gives you a sense of context.