The paragraphs about OO and Ada did not ring 100% true to me. OO was not added to Ada until 1995; The project was cancelled in 1994. I just pulled Grady Booch's "Software Engineering with Ada" C 1987, and it does have 8 pages on OO, but all it is talking about is packaging and encapsulation - the word "object" is not really defined. I.e, if your plane has a throttle, you'll write a 'throttle' package (e.g. module).
On the other hand, he does talk about IBM's use of Ada. They used a subset of Ada as a design language. These were the days of full on waterfall. And, the book's conclusion is quite giddy, prophesying that Ada will become the langue of choice, and extolled for enabling safe, maintainable code. Well, naturally, you can create horrible code in any language, and bork up any project with bad planning and execution. I recall working for a boss (until he was fired) that fully drank the koolaid - I'll spare you the number of steps you were supposed to, and the number of different CASE tools we were planning to use - years of work before the first line of code would be written, and then of course you would do "bottom up" development, coding each function, on and on, until you had a 'big bang' integration. Fortunately upper management saw how flawed that was, and we were able to do a much more sane process described as "design a little, code a little, test a little. Design a little, code a little, test a little".
It is easy to point fingers at companies, and to be sure they are culpable, but the government forces much of this on the companies. I recall government reviews where we were held to the exact language of the contract despite us pointing out why X was a bad idea, wouldn't work, and so on, and you would just be treated like a criminal.
On a different (quite small) project, I was forced to emulate all kinds of buggy UI behavior in an upgrade - I wrote a bunch of code to simulate bugs, because otherwise, well, you aren't meeting the contract, and dialog A used to do X, why is it now doing Y? Trying to explain why you might want to fix bugs (and yes, we tested and proved it was correct) just got you nowhere. So we spent a bunch of money writing deliberate bugs in a very acrimonious atmosphere where any attempt to reason or change things when you found a flaw in the spec was just treated as trying to rip off the government. There's a reason defense contractors charge a lot - there is no end to the amount of illogical things you will be expected to do on your own dime.
To be fair, it is not always like that. I was able to run quite a few projects, and at the kickoff meeting I would say "we can do this in one of 2 ways, and you get to choose. One, we can follow every 'shall' ('shall' expresses a deliverable requirement in contracts) to the 'T', and any deviation will get charged to you. Or, we can meet regularly, more than called for in the contract, you can observe progress and see the project at any time (typically contracts only gave the government a few opportunity to see progress during a project), and we will discuss and solve problems as they come up. You'll have to trust me, but you'll have a lot more insight, and equally I'll have to trust you not to skewer me with non-performance over some 'shall' we agreed to not address". Almost always they went with the second option, and we did some type of XP/iterative development. But these were small, couple people efforts; that would probably never fly with 100+ people teams.