Earlier quoted context omitted.
It’s really a throwback to the old days of aerospace. From the 1930s to the early 1960s, the standard method was to iterate rapidly with relatively cheap hardware, to learn and fix problems as quickly as possible. The von Braun and Korolev teams operated this way, among others. They all blew up a ton of rockets. What changed was the necessity of completing Saturn V and landing on the Moon by the end of the 1960s. Apo…
I’m not sure 3200 full scale tests of Saturn V’s F-1 engine, 2000 in an iterative trial-and-error scramble to suppress combustion instabilities is what I would call “overengineered to cut out iteration” during Apollo http://www.yang.gatech.edu/publications/Journal/JPP%20(1993,...
There was of course a ton of testing at the component level, and iteration when necessary. This worked for Saturn V because it could be done for each component in parallel, due to the huge mid-sixties spike in funding. But at the level of the integrated system, most of the testing—and nearly all of the iteration—was cut out, since it would have to be done in series for the entire rocket (or its stages). Thus the design had to be set in stone before the vehicle ever flew. The first and second stages of Saturn V flew just twice before crewed flight began. This was the right process for Apollo’s unique set of requirements and resources, but it is a bad idea when you A) don’t have a hard deadline forcing you to forego system-level iteration and B) don’t have a spike in funding to accelerate the up-front development, which otherwise takes forever. Hence SLS.