4 ms·

Crushing only because their cadence is so slow compared to SpaceX. Their process seems much closer to the highly risk averse methodology of traditional incumben

by wahern 5mo ago

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. 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.

jeffrallen 5mo ago
Failure is not only an option, but is required. The more smaller failures you have, the more big successes you can have.
- card_zero 5mo ago
  Well, they just had a failure, so that spells great success, right? I'm unclear on the point of why having a rocket blow up when you're being slow and careful is more of a setback than having one blow up when you aren't.
  - pfdietz 4mo ago
    Necessary and sufficient are different concepts.
  - MarkusQ 4mo ago
    Information theory. If you are doing lots of small, incremental tests, burning through a lot of hardware doing all sorts of characterization and qualifying tests, learning a little bit from each one, you can make steady progress, finding your mistakes as you go. If instead you try to work out everything in painstaking detail, build a small number of prototypes that your calculations assure you should work, and one blow sup, you learn that...your calculations are wrong. Imagine developing software with no CI tests, where you only get to run one full system test every couple of months. Slow and careful means avoiding lots and lots of early learning opportunities.
- j1mc 4mo ago
  ah, yes ... there's no success like failure, and failure's no success at all.
locknitpicker 5mo ago
> 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?
- LunicLynx 4mo ago
  Is this a broken down budget you are talking about? I don’t know the numbers but that spacex has more money moving around does not seem surprising. Launching 100s of rockets per year is not free? Also did you do an accumulation over their existence? Blue had two orbital launches so far.
- panick21_ 4mo ago
  > Some reports suggest SpaceX's 1-year budget is around 20 times the yearly budget of Blue Origin. I have been following the Space industry for 1-2 decades and I would love to know what you base this number on. In terms of what we know, is that we know that at times in the 2010s BlueOrigin had almost the same amount of people while launching much less often, having many many fewer projects (like no human capsule, no Starlink). It is well known that Bezos spend more then 1 billion a year on BlueOrigin, people estimate 2-3 billion $. And that was in a period where their overwhelming spend was on New Glenn. The idea that SpaceX spent 20x that even on Starship is insane and not credible. In fact, every piece of evidence shows the exact opposite. SpaceX developed Falcon 9 at a incredibly small budget, like literally vanishingly small compared to what New Glenn in spending. And then SpaceX iterated on the design while generating revenue. New Glenn cost many, many billions before revenue and has a budget that is not that different from Starship will being more comparable to Falcon Heavy. We also have other evidence. Lunar lander document from NASA suggested as much. NASA estimate that SpaceX would assume 50% of the cost, Blue bid was much higher and they were less willing to self finance (at least initially). Those numbers suggested that SpaceX and BlueOrigin lander cost were not that different, except of course the SpaceX lander had much higher capability. And pretty much everything we know about Blue is that they spend a huge amount of money and are nowhere near as thrifty as SpaceX, specially compared to the same stage of development. SpaceX had to do that because they simply didn't have the finances. They couldn't just use the 1-3 billion $ of free money flowing into the company. I open to being proven wrong here with some actual numbers. But I have been following this space in detail and try to look at the best numbers we know publicly and follow some companies that estimate these things. For example, for early SpaceX NASA did a study on cost and how SpaceX could do it at these costs. So we have some good knowledge on that period. We can also look at when SpaceX raised money and do some estimates of their budget and so on. If there are reliable numbers out-there that exist I don't know about, I would love know what you are talking about.
lunar_mycroft 5mo ago
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).
- baq 5mo ago
  Yeah exactly. Blowing up the rocket is the easy part. Reliably blowing up rockets on a high cadence is hard.
- servo_sausage 4mo ago
  If one pad is the bottleneck, and the goal is to ramp up to be a spacex competitor, then build more than one... Falcon has shown the playbook, and the demand for launch... The goal should be 2-4 launch sites in the medium term; with a second site very early to avoid exactly this.
  - pbrum 4mo ago
    I was going to say this too. And since we're at it: does anyone know how many launch pads the Chinese private space companies have, combined?
  - lunar_mycroft 4mo ago
    Until recently, SpaceX only acquired new pads because they needed a completely new launch site (SLC-4 in Vandenberg) or needed to launch a vehicle that their existing pad(s) didn't support (Falcon Heavy for LC-39A, Starship for Pad A in Boca Chica/Starbase). Currently, Blue Origin's only orbital launch vehicle is New Glenn, and their Vandenberg pad is still under construction.
    - mr_toad 4mo ago
      Waiting until you need something and don’t have an easy replacement is how you end up with delays and bottlenecks.
      - 4mo ago
bob1029 4mo ago
> 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.
- mrsmrtss 4mo ago
  That's not how TDD works. You test the whole chain and all the components with tests and you can move from top to bottom with TDD, it's actually how you should do it.
  - dboreham 4mo ago
    It is however how most software testing is done.
    - junon 4mo ago
      "Most" is a gross exaggeration.
  - deleted 4mo ago
    [deleted]
  - SAI_Peregrinus 4mo ago
    There's a disconnect between TDD using all sorts of tests (unit, integration, hardware-in-the-loop, in-field, etc.) and TDD using unit tests only. Unit tests provide the least value/line of test code of all types of tests. They're important, since they can catch bugs earlier than other sorts of tests that can't be caught by a type system, but not sufficient to catch most bugs.
brookst 4mo ago
Risk aversion is very risky.
deepsun 4mo ago
Not true. In early rocket days, soviets tried to use "move fast and break things" approach. They even put artillery generals in charge, who very much liked the approach. The problem became apparent with several failed launches of moon lander, when rockets blew up or failed to deploy payload. So engineers spent month of assembling a lander that just got burnt. And when it reached its destination, it failed to perform, because they didn't test it separately extensively. Then they realized it is faster to spend a lot of time testing each part on the ground instead of launching it all together when any bug would prevent even testing the rest.

by wahern 5mo ago

jeffrallen 5mo ago

Failure is not only an option, but is required. The more smaller failures you have, the more big successes you can have.

card_zero 5mo ago
Well, they just had a failure, so that spells great success, right? I'm unclear on the point of why having a rocket blow up when you're being slow and careful is more of a setback than having one blow up when you aren't.
- pfdietz 4mo ago
  Necessary and sufficient are different concepts.
- MarkusQ 4mo ago
  Information theory. If you are doing lots of small, incremental tests, burning through a lot of hardware doing all sorts of characterization and qualifying tests, learning a little bit from each one, you can make steady progress, finding your mistakes as you go. If instead you try to work out everything in painstaking detail, build a small number of prototypes that your calculations assure you should work, and one blow sup, you learn that...your calculations are wrong. Imagine developing software with no CI tests, where you only get to run one full system test every couple of months. Slow and careful means avoiding lots and lots of early learning opportunities.
j1mc 4mo ago
ah, yes ... there's no success like failure, and failure's no success at all.

locknitpicker 5mo ago

> 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?

LunicLynx 4mo ago
Is this a broken down budget you are talking about? I don’t know the numbers but that spacex has more money moving around does not seem surprising. Launching 100s of rockets per year is not free? Also did you do an accumulation over their existence? Blue had two orbital launches so far.
panick21_ 4mo ago
> Some reports suggest SpaceX's 1-year budget is around 20 times the yearly budget of Blue Origin. I have been following the Space industry for 1-2 decades and I would love to know what you base this number on. In terms of what we know, is that we know that at times in the 2010s BlueOrigin had almost the same amount of people while launching much less often, having many many fewer projects (like no human capsule, no Starlink). It is well known that Bezos spend more then 1 billion a year on BlueOrigin, people estimate 2-3 billion $. And that was in a period where their overwhelming spend was on New Glenn. The idea that SpaceX spent 20x that even on Starship is insane and not credible. In fact, every piece of evidence shows the exact opposite. SpaceX developed Falcon 9 at a incredibly small budget, like literally vanishingly small compared to what New Glenn in spending. And then SpaceX iterated on the design while generating revenue. New Glenn cost many, many billions before revenue and has a budget that is not that different from Starship will being more comparable to Falcon Heavy. We also have other evidence. Lunar lander document from NASA suggested as much. NASA estimate that SpaceX would assume 50% of the cost, Blue bid was much higher and they were less willing to self finance (at least initially). Those numbers suggested that SpaceX and BlueOrigin lander cost were not that different, except of course the SpaceX lander had much higher capability. And pretty much everything we know about Blue is that they spend a huge amount of money and are nowhere near as thrifty as SpaceX, specially compared to the same stage of development. SpaceX had to do that because they simply didn't have the finances. They couldn't just use the 1-3 billion $ of free money flowing into the company. I open to being proven wrong here with some actual numbers. But I have been following this space in detail and try to look at the best numbers we know publicly and follow some companies that estimate these things. For example, for early SpaceX NASA did a study on cost and how SpaceX could do it at these costs. So we have some good knowledge on that period. We can also look at when SpaceX raised money and do some estimates of their budget and so on. If there are reliable numbers out-there that exist I don't know about, I would love know what you are talking about.

lunar_mycroft 5mo ago

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).

baq 5mo ago
Yeah exactly. Blowing up the rocket is the easy part. Reliably blowing up rockets on a high cadence is hard.
servo_sausage 4mo ago
If one pad is the bottleneck, and the goal is to ramp up to be a spacex competitor, then build more than one... Falcon has shown the playbook, and the demand for launch... The goal should be 2-4 launch sites in the medium term; with a second site very early to avoid exactly this.
- pbrum 4mo ago
  I was going to say this too. And since we're at it: does anyone know how many launch pads the Chinese private space companies have, combined?
- lunar_mycroft 4mo ago
  Until recently, SpaceX only acquired new pads because they needed a completely new launch site (SLC-4 in Vandenberg) or needed to launch a vehicle that their existing pad(s) didn't support (Falcon Heavy for LC-39A, Starship for Pad A in Boca Chica/Starbase). Currently, Blue Origin's only orbital launch vehicle is New Glenn, and their Vandenberg pad is still under construction.
  - mr_toad 4mo ago
    Waiting until you need something and don’t have an easy replacement is how you end up with delays and bottlenecks.
    - 4mo ago

bob1029 4mo ago

> 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.

mrsmrtss 4mo ago
That's not how TDD works. You test the whole chain and all the components with tests and you can move from top to bottom with TDD, it's actually how you should do it.
- dboreham 4mo ago
  It is however how most software testing is done.
  - junon 4mo ago
    "Most" is a gross exaggeration.
- deleted 4mo ago
  [deleted]
- SAI_Peregrinus 4mo ago
  There's a disconnect between TDD using all sorts of tests (unit, integration, hardware-in-the-loop, in-field, etc.) and TDD using unit tests only. Unit tests provide the least value/line of test code of all types of tests. They're important, since they can catch bugs earlier than other sorts of tests that can't be caught by a type system, but not sufficient to catch most bugs.

brookst 4mo ago

Risk aversion is very risky.

deepsun 4mo ago

Not true. In early rocket days, soviets tried to use "move fast and break things" approach. They even put artillery generals in charge, who very much liked the approach. The problem became apparent with several failed launches of moon lander, when rockets blew up or failed to deploy payload. So engineers spent month of assembling a lander that just got burnt. And when it reached its destination, it failed to perform, because they didn't test it separately extensively. Then they realized it is faster to spend a lot of time testing each part on the ground instead of launching it all together when any bug would prevent even testing the rest.