And this isn't limited to aerospace. My wife has spent a career in pharma (drug save & pharmacovigilance specifically) and it's the same way there. People complain about rigidity and sluggishness in these industries but there absolutely is an ingrained attitude of documentation and process compliance that pervades. At one point -- and this was just last year -- my wife took over running a monthly safety report that involves manipulating a bunch of data in Excel. Even that has a 9 page instruction guide, and since she now owns the output she also owns maintaining the manual.
Too often in the land of software we underestimate the potential negative impact the traditional "move fast and break things" approach to product development can have when it comes to real world use in mission critical systems.
On the other side this unwillingness and mental non-acceptance of those reports/manuals/etc. as a wasteful activity frequently comes from the understanding that there are more efficient ways of doing things, and that drives the "software eating the world" effect. While I naturally don't know the details of the case you mention and pharma is far from the domains I've been in, yet in many business/enterprise situations the software approach is to code the many-page guide into business logic, including ETL-ing the data instead of manual import, etc.
Move fast and break things brings you to the Moon in a decade using primitive tech, where is total process compliance can't do that even in 50 years using much more advanced tech.
So, an amusing anecdote related to your second paragraph - one reason it's taking so long the second time around is everything has to be repeated. They lost the knowledge of how to make rocket stages and engines of that size, and had to re-learn those lessons.
It's also quite important to remember how many lives were lost (or nearly lost) because of "breaking things" in the Apollo program. Something that's not nearly as acceptable today than it was at the height of the cold war. Something that directly implies moving more slowly and being more sure that everything works the first time, every time.
Seconded. People burned alive until we learned. Surely there is a middle ground that will let us speed up while staying fairly safe, but it's important to remember that outside of software, many rules are written in blood.
I don’t hold a strong opinion either way - in terms of process and documentation versus freestyling it - but that fire was predicted, and I think the concerns were documented.
It can and did happen again, twice, on the shuttle project. Both the O rings and the ice damage were documented.
Ultimately, any process (or lack of process) can be subverted by a bad culture. And unreasonably excessive process - as perceived by the participants - can damage culture as much as not enough.
The problem is that culture is ineffable, so we try to nail it to the ground with whatever we can think of.
a lot of people died in germany, the ussr, and the us making those rockets work. and in exchange for that we planted a flag there and have a handful of rocks in a glass viewing box.
move fast and break things worked real well for the folks who got literally creamed while they were viewing the titanic.
Too often in the land of software we underestimate the potential negative impact the traditional "move fast and break things" approach to product development can have when it comes to real world use in mission critical systems.