Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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. Apollo program head George Mueller recognized that, with the planned number of iterative tests, they were going to be too late. He made the gutsy decision to launch “all-up”: spend a ton of money up front to overengineer the crap out of the vehicle and cut out most of the iteration. It worked!

But alas, the aerospace world overlearned the lesson and has been cargo-culting it ever since. Mueller’s decision was purely a matter of expediency to meet Kennedy’s goal and beat the Russians. It wasn’t a statement that this was the best way to do engineering, absent those constraints. To make matters worse, all-up only works under the funding conditions of Apollo: a massive spike in funding to cover the up-front cost. Without that spike, the costly development phase has to be stretched out, and the whole thing ends up taking longer than iteration. In other words, you can save time this way when money is absolutely no object, but otherwise you lose time. See Boeing’s SLS: basically 15 years of development and they just static-fired it for the first time. Launch is maybe a year away.

We’ve all gotten used to the all-up style of development, and SpaceX’s rediscovery of rapid iteration makes it seem like a new and untested way of doing things. But I think the dominant narrative—that all-up is prudent and conservative while iterative is risky—is completely backward. All-up carries a massive amount of risk that fundamental design issues won’t become apparent until the tremendously costly development phase is done. Iteration allows assumptions to be tested and modified as quickly as possible. Most of SpaceX’s early ideas about reusability turned out to be wrong. If they had committed all the money and time to those early concepts before flight-testing, they would have never accomplished it. The early rocketry pioneers operated this way, and it’s why they accomplished the things they did. Maybe SpaceX will finally free the space industry from perpetually repeating what worked for Apollo, which after all operated under unique political conditions.



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.


Granted, I am biased towards propulsion, but we are not talking about some bolt or bearing as a 'single component'. The propulsion system is a complex thermodynamic cycle, with tanks, turbopumps, preburner, regenerative cooling, injection, engine, nozzle, etc. Seems to be a rather involved 'component'.


That's just one engine - much less than a 5-engine stage even on a test stand, not to say about flying.

And combustion instabilities they were fighting were rather novel at the time, the engineers basically had no other options than to test a lot of variants - and invent debugging techniques with "bombs in the chamber" along the way. Fortunately it worked - low pressure of F-1 helped to mitigate problems of size.


I don’t understand your first paragraph - is this related to the F-1 development having strong iterative components?

Also, Combustion instabilities date back to at least the A4/V2, not quite new, and largely the same engineers.


The F1 is a bigger (!!) version of the same engine. It's got the same crucial features:

1. turbo-pumps

2. the nozzle is cooled and the fuel warmed by making the nozzle out of tubes through which the fuel passed

3. holes drilled in the tubes so fuel leaked into the combustion chamber to provide boundary layer cooling

I think the pogo-ing was solved the same way, too - putting baffles in in various places.


By that logic essentially all cryogenic engines are “the same”.


In a similar vein, all modern jet engines can trace their core features back to the Ohain engine (not the Whittle engine).


I agree that Apollo set the stage for a lot of things in aerospace. It's worth noting that the death of the entire Apollo 1 crew actually led to less iteration in the late stages of the program.


The acceleration of aerospace development costs started long before the Apollo program.


That is definitely true. I do think Apollo was the turning point when rocketry changed from a development process focused on rapid iteration (seen as late as Redstone-Jupiter-Juno) to one focused on a lengthy design phase (and component testing) with late and limited integrated testing. The roots of the shift are probably in the ICBM world, but Apollo was when civilian rocketry (over)learned the lesson.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: