It is not exactly cheap to do it like SpaceX does, but the savings in time and increases in robustness may very well offset the cost of all the prototypes that undergo a RUD.
Each Starship has 30+ engines required per flight and tons of precision welding. All of it can now be made in a month. That means massive cost savings going forward, the faster each can be made
Rather than spend 10 years designing and building one telescope, they could spend 2-3 years and keep refining the hardware, with multiple types on the same platform
E.g.,
Design_A fails. We quickly pivot to Design_B, which works. However, we don't spend the time ultimately understanding why Design_A failed. This can be operationally great, but it can also risk conflating being lucky with being good. If you don't fundamentally understand why the thing failed the first time, it's much harder to understand if those failure modes are fully mitigated.
Personally, I think the ideal approach is to have SpaceX continue the rapid enginneering iterations, but give NASA (or some other entity) the resources to research the rest.
Take for example the work on the failure of Amos 6. They went really deep into that one and its a pretty interesting result from a scientific perspective.
On the other hand, there is no point in doing endless science on why the pad blew up during the first orbital flight test. They solution was already in development anyway and its pretty clear that the solution would migrate the problem. It might introduce new problems but the old one wasn't happening again.
So there is a limited need to the exact detail of underground steam explosion or whatever exactly happened there.
Did you read TFA? It's about the release of an extensive report documenting why Design_A failed and what corrections are to be made regarding each specific failure.
Also, from the HN Guidelines: "Please don't comment on whether someone read an article. "
This is just basic science: theory experiment result.
And with all the documentation and instrumentation on the flights, The theories can be experimentally validated or invalidated.
This isn't like some agile programmer shoving in a couple hundred lines of code over the course of a one week sprint.
1) Risk on safety critical operations is not something people tend to want to roll the dice with.
2) The nature of the industry makes each trial pretty expensive. Over decades, the shuttle only had something like 135 launches and the managers still didn't have a good handle on the actual risk.
Sort of proving the point here, no? There is a reason SpaceX has gone to orbit more times than the Shuttle has. Soon they will have launched more Starship prototypes than the shuttle ever did. And they will be safer, because SpaceX understands why their rockets fail.
Obviously this strategy does not work with humans in the loop. It might have been impossible to do what SpaceX is doing now in the 80s given the advancements in computer control and simulation that have happened since then.
I don't think so, for the same reason you identified: it only works when the risk isn't safety critical (ie when humans are in the loop). In other words, it's acceptable when risks are low. It's the same reason NASA is more risk-tolerant with non-human-rated missions. But keep in mind CCP is also meant to transport humans. The risk we'd want to bolster against is the human biases that lead us to get complacent. There are some instances that make me wonder about that with SpaceX, but I'm giving them the benefit to the doubt that they've learned from those.
1) The failures themselves aren't all too complex (relatively speaking), and by the time the design made it to a flight vehicle it has been vetted for all immediately knowable risks. The rest you discover during flight. And even then the actual nature of the problems rarely (if at all) are esoteric or present breakthrough scientific discoveries.
2) Failure in rocket launches are catastrophic leaving behind very little evidence. There could be a limit to how much you can learn. But...
3) ...SpaceX is a business serving customers, and if a pivot means going away from a complex cloud of possible failures (known and discovered) to more robust, more deterministic, more reliable, you should do it.
4) At what level do you stop and go "this is fundamental enough"?
>The failures themselves aren't all too complex
The COPV failure mechanisms may not be terribly complex (e.g., voids or delamination), but managing the processes to mitigate them isn't.
>by the time the design made it to a flight vehicle it has been vetted for all immediately knowable risks.
SpaceX has already shown some bad processes that disprove this statement. E.g., the strut failure was due to poor supplier quality control, which is a relatively mature process in the industry. I'd give them the benefit of the doubt and say they've gotten better as they've matured as a company.
Failure in rocket launches are catastrophic leaving behind very little evidence.
The difference, I think, is that you are constraining this to launch failures. I'm talking about knowledge and data about individual component failures, from which you can derive the overall reliability of the design.
if a pivot means going away from a complex cloud of possible failures (known and discovered) to more robust, more deterministic, more reliable, you should do it.
I don't disagree that more simple tends to be more reliable. However, the point was that iteration doesn't necessarily advance knowledge of failure. I think these two points are not mutually exclusive. A good business case doesn't mean it makes for good engineering or good science.
At what level do you stop and go "this is fundamental enough"?
It's a tough question. But if you can't characterize why a failure mode occurred reasonably well, that's probably not good enough. So if they say, "We know voids in the COPV manufacturing process contributed to the failure" they should probably make sure they have a good understanding of why they occurred. (And maybe they have at this point)