alt Hacker NewsCrushing only because their cadence is so slow compared to SpaceX. Their process seems much closer to the highly risk averse methodology of traditional incumbents than to SpaceX's style. Failure becomes a self-fulfilling prophecy.
Rockets are ridiculously complex. Slow-and-steady wins the race makes sense for many individual components, depending on how well understood the problem domain is, and your ability to rigorously model things. But if you take that approach when testing all the thousands of components together, which is simply just too complex to exhaustively model[1], you'll never get anywhere. You have to be prepared to not only break some eggs in epic fashion, but to break many as quickly as you can, so you can parallelize your problem solving and iterate faster.
[1] At least without a large multiple in time and monetary expenditure that ends up costing more than even the US (government and private capital combined) is prepared to spend.
Replies
No, this would be crushing regardless. Even if Blue Origin had dozens of rockets ready to go, they can't fly without without the pad, which will take around a year to repair (based on previous examples).
Risk aversion is very risky.
Failure is not only an option, but is required. The more smaller failures you have, the more big successes you can have.
> Crushing only because their cadence is so slow compared to SpaceX. Their process seems much closer to the highly risk averse methodology of traditional incumbents than to SpaceX's style. Failure becomes a self-fulfilling prophecy.
This is a silly perspective. Some reports suggest SpaceX's 1-year budget is around 20 times the yearly budget of Blue Origin. Of course SpaceX can afford to blow up rocket after rocket. The radical difference is not methodologies, but how much cash is being thrown at the project.
For perspective, apparently the whole lunar lander program ran on a 1-year budget much similar to SpaceX's, and thus 20 times larger than Blue Origin's. Where they also highly risk- averse?
> if you take that approach when testing all the thousands of components together, which is simply just too complex to exhaustively model[1], you'll never get anywhere.
This is exactly why ideas like test-driven development don't work well as a general approach.
Most realistic systems exhibit non-linear interactions where correctness is not compositional. Local correctness does not compose upward in any meaningful sense. Top-down design (working backward from the customer) allows for you to perform what is effectively one big global search. Bottom-up design (TDD) requires many local searches that all have to fit together perfectly at the very end. With units & composition, the consequences of component A's interactions with component B may not be considered until nearly the end of the project. If you are testing an integrated vertical, you will discover these interactions much earlier.