Not disappointing - the more things that go wrong during the extensive series of tests developed and cataloged over the past several decades, the more we can correct and cement into permanence.
I'm looking forward to SN747 (the number corresponds with one of Boeing's standardized atmospheric flight models) sometime in 2024. I'm probably not thinking big enough though.
Musk was pretty clear in an interview that he does want things to blow up. He wants the testing to push and exceed the limits so those limits become well defined. It sounds quite reasonable.
> Musk was pretty clear in an interview that he does want things to blow up.
I get that fanboys are excited and they see the Musk world through rose-tainted glasses.
But SpaceX was planning on flying this vehicle. And it exploded.
How does anyone anywhere believe in that? Obviously this outcome was not planned. If anyone wants to fly a vehicle to test other stuff, they don't want it to blow up prior to it.
I'll reiterate a point I made deeper down: obviously the failure wasn't planned or intended. But the overall process of being failure tolerant and having a high rate of failures, was.
You can spend your resources on doing careful modelling and over-engineering and conservative testing to always stay within limits, or you can go fast and loose and discover those limits the kinetic explodey way. SpaceX chose the latter strategy.
Also, not a fanboy. On a personal level the guy's a prick. But the strategy that SpaceX is employing is sound and tested. It's the same R&D strategy that was employed by Skunkworks, which is arguably the most successful aerospace R&D story in the entire history of our species.
> You can spend your resources on doing careful modelling and over-engineering and conservative testing to always stay within limits, or you can go fast and loose and discover those limits the kinetic explodey way. SpaceX chose the latter strategy.
Again, this baseless assertion is just plain wrong on many levels, and flies in the face of basic engineering practices.
At best, you're confusing a consciencious choice of allocating piles of resources to avoid bottlenecks and time constraints, such as losing a prototype which is a project death sentence to your general aerospace research project, with plain old incompetence.
Engineering 101 teaches that when in doubt err on the safe side. Your assertion is the exact opposite because... Because what? What do you believe is the trade-off of wasting time and resources trying to fly intentionally half-baked designs that define the critical path of the project?
Please spend a moment thinking about what you've said to try to see how absurd it is to waste time and resources for nothing at all.
> Engineering 101 teaches that when in doubt err on the safe side.
Nonsense. You can't discover limits if you always stay within them. Commercial engineering, sure. But R&D is by definition the process of exploring an unknown parameter search space. And considering that spaceX have achieved what STS has failed to do with 1/10th of the STS budget, I'd say they're not doing terribly badly with their chosen R&D strategy. You seem to have a deeply ingrained misconception about what R&D actually entails and how it's different from both commercial engineering and designed experiments.
Erring on the safe side is what they're doing with their manned missions. Cargo missions are medium risk and occasionally do dirt-cheap launches to deliberately try risky scenarios. R&D ops is deliberately high risk and low process overhead. They rather someone just try something and see what happens instead of spending 6 months writing an experiment plan and getting it validated etc. as you would see in the pharma industry for example. I'm not sure why you're struggling to comprehend this fairly simple and fairly standard strategy.
In R&D things blow all the time.
You just usually don't see it. In labs when they are looking for new drug or vaccine - thousands of variants fail. And it's ok. When you are developing anything new - you do thousands of try and fail. IF you don't - then you will even ever invent anything new. The best you can do is a little bit upgraded iteration.
And here a few fails and it is disappointing?
Nope. Its the only way to discover something new.
There are world's of difference between a prototype accidentally blowing up because a design fault was unnoticed up to that moment, and this absurd spin on this accident about how these accidents are sought after and desirable. They aren't. They are always problematic and a setback, and in some projects even project-killers.
So, enough with the bullshit about how this accident is good news. It isn't. Even if the project can easily recover from this setback, it's still a setback.
And most fresh engineering graduates know nothing about real engineering.
You don't intentionally half bake the design, but you do intentionally try to exceed whatever your maximum design specification is.
The wing flex test, for example. 150% of the expected maximum flex the structure will experience during real operation.[1]
Even with software, you can't stop at "well I think this is the maximum load this service will handle in production." You need to know what will happen if that expectation is exceeded. Maybe nothing, or maybe your initial estimate was too high to begin with.
> And most fresh engineering graduates know nothing about real engineering.
And that's ok, that's why they are supervised by experienced engineers, who in turn in relevant projects with some complexity answer to senior engineers.
But even then screwups might happen, and sometimes it's ok. Nevertheless, unlike the spin that is being given to this disaster, that doesn't mean accidents are desirable or sought after.
Particularly when the accident consisted of exploding the prototype that was already scheduled for flight tests.
> Engineering 101 teaches that when in doubt err on the safe side.
This sounds like lecturing birds on how to fly (Nassim Taleb quote below.) They'll possibly fly people to the space station today. Maybe they have engineering 101 down? If they're breaking guidelines in a 101 level course, then maybe they're just making amendments to the rules. Maybe the textbook writers need to make a revision.
The greatest problem in knowledge is the “lecturing birds how to fly” effect. -Nassim Taleb
You care too much about the vehicle. What they are testing isn't the vehicle, they are testing the production processes.
I'm confident the vehicle design will work once they get a handle on the production. They got really good simulation tools for the vehicle flight part of the problem.
> You care too much about the vehicle. What they are testing isn't the vehicle, they are testing the production processes.
No, they clearly are not.
They are designing a vehicle. One of the design requirements might be a better production process, but as it is very obvious to everyone their goal is not to produce a vehicle that blows up unexpectedly.
And the vehicle blew up unexpectedly, when it was scheduled for a flight test.
The goal of SpaceX is not to implement the broken window fallacy.
He does want things to blow up, but he vary rarely wants this thing to blow up.
If things don't blow up, they're spending too much time being careful, since the cost of being reckless at this stage of development is less than the cost of things blowing up on a regular basis.
If this thing blows up, well now that was just unfortunate. That was a not-entirely-free test article or lawn ornament and now the test failed so they can't be sure that it blowing up didn't hide another issue 10 seconds down the line. Obviously it would have been better if the person on the ground just remembered to check the whatchyamaculit before the test and prevented it from blowing up (which doesn't change the fact that it's not worth it to pay people to check every whatchyamaculit at this stage of development).
That's the point - they're discovering the limits.
The other way to do this would be to over engineer, have more conservative testing, etc. But Musk has been clear that they've explicitly chosen a strategy of fast iteration, and breaking things instead. And that's one of the primary things that gives them an edge over NASA.
You don't need to be an aerospace engineer to be aware of the spaceX R&D strategy which has been spelled out pretty clearly by Musk and others in various interviews.
I'm not saying the failure was intended, I'm saying the reason there are so many failures because they opted to go hard and fast, while government funded shops like NASA can't afford to have such a high failure rate because of the optics and politics. This modality to R&D isn't at all unique to aerospace and is more of a business/management issue so I'm not sure why you think an engineer would have anything more meaningful to say.
As Kelly Johnson of skunkworks said, you can't have innovation unless you are prepared to see failures.
The whole fundamental concept of innovation is that there is no plan. If there's a clear path to get to where you want to go, then you don't need to innovate. Innovation is the act of exploring the unknown regions of the problem search space. No, there's no guarantee they picked an optimal strategy. If such a guarantee were possible, they wouldn't need to be trying and failing in the first place.
What there is clear evidence of, is you generally reach your goal faster if you're more risk tolerant. And that's very well understood by now. Various r&d folk from NASA have also said that they wish they could go harder and faster. But because they're micromanaged by congress, every failure is very expensive politically.
The stated attitude of a company as public as SpaceX is carefully tuned and measured. The actual attitude internally is likely to be substantially different.
> The stated attitude of a company as public as SpaceX is carefully tuned and measured. The actual attitude internally is likely to be substantially different.
Its still a Musk corp, and as I was told at Tesla 'Elon gets, what Elon wants.' Its really odd philosphy but not entirely surprising, because I was going for Operational Support roles, not Engineering where its understood he has full reign, and it was felt in those department's leads/directors.
As for SN4, well, what's the saying: Progress is messy. Aerospace has lots of failures. Onto SN5!
Please don't let these rather aggressive comments from Ruminator and others stop you commenting.
You put forward perfectly reasonable observations and it is frustrating when someone tries to silence others using the appalling Credentials Fallacy.
It is perfectly logical to say at the macro level our "take risks, move fast" strategy will produce more failures, whilst at the micro level being very disappointed at each failure.
Now, if this was a manned mission with life at stake I would expect the risk approach to be modulated accordingly. But even so, astronauts are not civilian passages and even they knowingly embrace flying at high risk. It would be interesting to know how (and if) SpaceX has approached derisking manned flight. Because the PR from blowing up humans is not good whether you're NASA or a private company.
2. look for lapses in construction technique and QA
In car racing, you'll never learn to be a fast driver unless you can drive right at the limit, and you'll never know where the limit is unless you exceed it now and then.
Destructive tests are planned accordingly, and the outcome is known beforehand. The questions to be answered are a) which failure mode, b) quantify limits of a failure mode.
This was not a destructive test. Their plan was to fly this same vehicle next. Now they can't because it blew up.
This wasn't a test to destruction. It was a static fire test. While I'm sure there's good data to leverage, I highly doubt there were any details in the test plan for characterizing catastrophic failure.
Yeah, but if you dont want it to explode and it does - it's not a good thing. Destructive testing is something different, like the mission abort test they did a while ago.
> Not disappointing - the more things that go wrong during the extensive series of tests developed and cataloged over the past several decades, the more we can correct and cement into permanence.
To some extend, but just as with software, I’m super happy if my program just has zero bugs after all the testing is done.
This has never happened, but it’s nonetheless something to strive for.
I'm looking forward to SN747 (the number corresponds with one of Boeing's standardized atmospheric flight models) sometime in 2024. I'm probably not thinking big enough though.