Full explaination of Starship Flight 3 failures (SpaceX Official)

Do both. Integration hell is inescapable.

They've been firing them on the ground pretty often and didn't catch it, so clearly the filtration issues only happen when actually flying.

And, of course, that's still overlooking all the other tests they were able to do. They were able to verify that hotstaging will work, they were able to get the basic concept of the propellant transfer to work and they got data on reentry heating as well as on the viability of using Starlink to transmit through reentry.

A full-duration static fire would maybe catch some issues with propulsion and fueling, but then you're still static without the same free-flight vibrations, let alone the wild maneuvering of flipping around a building with a backyard swimming-pool's amount of liquid in it.

"Better tolerances" is a vague statement; adding more tolerances to all the things just makes the cost explode. Tolerance smarter, not harder.

This method has already been proven to be infinitely better than the old school approach. Falcon is the most reliable rocket in the world and capable of landing its booster back safely to earth, something which thought impossible by basically everyone in the industry. It took years of physical iteration to iron out all the problems though, see this video from SpaceX of all their years of failed attempts: https://www.youtube.com/watch?v=bvim4rsNHkQ

Anyone who has ever built a physical product will tell you that theory and good engineering are important, but once you start to actually build something you enter "integration hell", which means you need to physically exercise your product end-to-end many MANY times, and iron out all of the edge cases that reality presents.

It has nothing to do with "better engineering" and everything to do with complex systems interacting with physical reality.

Stuff Made Here (YouTuber) made a video where he built a disc launcher, which is a great example of what the process is like. He put quite a lot of engineering and design work into the project, but eventually entered integration hell at some point and just had to iterate and problem solve by repeatedly firing test disks until all the kinks were worked out. https://www.youtube.com/watch?v=t9rClZrbnrQ

It's cheap because it's rapidly reusable. That depends on rapid reusability of the launch system, which still needs weeks of repairs between launches. And it depends on every component of the rocket working and not needing testing or significant refurb between reuse, which includes all 19,000 heat shield tiles. Rapid reusability is required to make it possible to do 15 refueling flights per starship mission beyond Earth orbit. Doing no more than 15 refueling flights depends on meeting payload specs, not yet proven. This is far from a complete list of even the known unknowns and their unknown solutions that each may need multiple iterations to establish reliability. Each iteration prior to safe return costs a booster and a Starship and 39 engines.

I encounter a lot of cases where people mistake Agile for "that's how people do project management now" and try iterative development when they shouldn't. Mostly in projects related to, but not directly involved in implementing software. This could be the most expensive case of "don't mimic how the software people do it."

"I really don't get a sense that this "rapid iteration" approach is a good replacement for better engineering and more care."

A huge rocket torn to pieces looks expensive, but given the way SpaceX builds them, may well be cheaper than personal costs of extra engineers over several months.

Also, basically you want perfection. Perfection is unattainable, especially in a prototype of a brand new system. If Starship flew perfectly on its first or second or third launch, I would be nervous that something really big and random lurks in the background.

Looking at Falcon 9, the iterative approach was a great success. As of now, Falcon 9s are crazy reliable.

Apparently they use raptor exhaust gas to pressurize tanks, and it is speculated the filters are getting clogged from the water vapour in the exist gas freezing.

Also, that rocket was always destined to be throw away, just like SLS 1 and 2. Purely test articles.

> I really don't get a sense that this "rapid iteration" approach is a good replacement for better engineering and more care.

It sounds like you're saying you know how to design, build & test orbital rockets better than the company that in the last ~decade designed and built what is now the world's most reliable rocket, the only rocket that can be reused and that now puts more mass into orbit than every other rocket and country on the planet combined, by a very, very large margin.

I.. ah, trust SpaceX.

That's a very reductive way of looking at it. They didn't blow up a rocket to find out a specific thing.

The build the infrastructure, build production line, train the team, prepare the rocket, launch the rocket and then attempted the two different parts of the rocket, only the combine them and refly them again to find out that in a specific case where the rocket does specific sequences of events certain assumptions they made in the design that were not obvious in simulation could lead to problems. Even more importantly the validated 1000s of other assumptions they made that turned out to be correct.

> or handled with better tolerances

This is the fundamental mistake in your thinking. It leads to an approach where on every layer of the design every engineering team introduces huge tolerances, just to be sure. This then leads to a system where any individual part has huge tolerances but the system as a whole is costly and performs badly.

One of the first and most important design principles at SpaceX is to challenge requirements. Rather then just adding tolerances you do only what you think you will need. If you do not do to little at least some of the time, you haven't been aggressive enough.

SpaceX probably made many design choices with very tight tolerances where a conservative engineer would have added them. Turns out 1 or 2 of them bit them in the ass, but with this test flight they likely validated that many others are fine.

> I really don't get a sense that this "rapid iteration" approach is a good replacement for better engineering and more care.

What evidence are you basing this assessment on? What large reusable rocket was build with the traditional approach? The only thing that is even remotely close (and it really isn't very close) is the Space Shuttle. The Space Shuttle was very expensive to develop, well above 10 billion $ and didn't achieve many of the goals it had. And it wasn't reusable, with the large external tank not being reusable and the solid rockets being not practically reusable.

If NASA tried to build the Shuttle today, with modern requirements for safety, it would cost much more.

Maybe it will end up being more expensive and fail as a project. But its very early to suggest that. The have developed arguable the best engine ever and have launched the most powerful rocket in history. Not bad so far I would argue.

You're really advocating for the NASA "perfection engineering" approach, which has demonstrated itself to be ineffective (for decades) when compared to SpaceX's approach?

Not necessarily wrong to not try to relight them. Maybe it should have started the landing burn earlier, or maybe there was no saving it with six O2 starved engines.

If the engines only have enough fuel to do the boostback burn once, they could be "disabled" in a hardware sense too?