SpaceX blew up another Starship.
Like… Mercury, Gemini and Apollo didn’t blow up four or five times. The shuttle program killed two shuttles’ worth of astronauts, but that was over 100 missions. And it still wasn’t acceptable.
Is this on purpose/sort of by design, like the Muskheads keep claiming? What the hell is going on?
Different design methods, SpaceX is backed by someone who can afford to do design by trial and error.
“Move fast and explode things.”
Here are 1300 posts on Starship development history & the SpaceX way of doing things.
The short version is SpaceX is far more willing to screw up in public & learn quickly and cheaply.
Whether they have the balance at the optimal point is certainly debateable.
That they are aiming for a learning curve utterly incomparable to NASA is fact; uncontroversial fact.
You (OP) have also made a false comparison between NASA manned systems and SpaceX unmanned systems.
So far SpaceX manned systems are outperforming NASA manned systems as to reliability. From an admittedly small baseline.
And SpaceX’s unmanned success rate dwarfs NASA’s over the decades. Not so much in the last decade, but NASA is now mostly flying 50yo mature unmanned designs. You’d hope by then they’d have nade them reliable.
Musk is a software developer. The mindset of software developers is to “put in a bit of effort and see how it goes” - it takes many, many iterations of this before you get something that is acceptable.
True Engineers, however, have a different approach, since building several bridges that fall down before you get one that stands up is not realistic.
“Move fast and break things”; a mentality that works fine with non-critical commercial software, not so much with hardware and mission-critical systems. Thus far, SpaceX has been fortunate that none of the uncommanded destructs has near or on inhabited land or struck a vehicle in transit but they’ve gotten far closer than traditional range safety requirements would permit. It is also the case that many of these failures are a result of poor design or should have been caught in testing, and while analysis and ground testing can’t present all of the in-flight conditions, a focused test program can provide more insight into flaws and failures and actually save time and effort over the “fly-break-fly” approach.
Although Musk did write code for Zip2 very early in his career, it was by all accounts pretty bad code. He has more recently demonstrated apparently little to no understanding of modern software architecture and engineering given his statements regarding Twitter. As for software development approaches, there are different strategies for doing so depending on what kind of system is being developed. The “code a little, break a little” is fine with making apps or within small teams but large software development efforts break under the strain of defective code and shifting requirements, which is why Agile has gotten a really bad rap (even though for certain types of development it can be very flexible). If you were writing mission critical software for, say, managing a nuclear power plant or flying an aircraft, it is important to define good requirements and rigorously test the system dynamically in simulation (“software in the loop” or in cases where physical interactions and latencies pose a challenge “hardware in the loop”) to catch errors that would not be caught in static analysis and individual unit testing.
As you note, this approach doesn’t apply well to hardware systems where ‘failure’ of a bridge (or launch vehicle) is catastrophic and the root cause may not be well understood if the physical evidence is not available for inspection and data is sparse.
Stranger
Fortunate, or careful enough to avoid such accidents (even if not as careful as NASA would be)?
Interesting claim. Only one question: How come none of the other space companies that use the mentality you describe manage to hold a candle to SpaceX?
They plan for these problems and the rockets have the ability to self destruct if things go wrong.
Fair comparison. There’s plenty of testing to the failure point in hard engineering as well, but it’s not necessary to have an entire bridge fail to find a problem… usually that is… we all know about the Tacoma Narrows but that problem was not well understood before then. Rocket ships are bit more difficult to test in real conditions though.
In fact, SpaceX took this approach with development of the Falcon 9 and Heavy (because they wanted EELV later NSSL certifications as well as NASA certification for Commercial Resupply and crewed missions), and developed some fairly innovative ways of doing ground testing (despite Musk ranting and raving about how this was “slowing them down”); as a result, they got a lot of information about failure modes that were corrected before flight. SpaceX has not done this for ‘Starship’ thus far because they are launching from a private range with purely FAA AST approvals and under internal funding, and you can see how well this is going for them with 5 out of 9 launches either completely failing (despite the desire to characterize them as successful) and one partial failure. Many of these failures have been for pretty dumb reasons starting from F.light 1 where (per Musk’s direction) they did not use any kind of acoustic suppression or reinforcement on the flame duct, resulting chunks of concrete being kicked back up into the engine bad and damaging multiple engines as many experienced people in the rocket launch industry warned would happen. Failures, especially early in the life of a new design vehicle will happen, but you generally don’t want to lose a vehicle to a stupidly easy cause that could be prevented by taking basic precautions and using good design practices.
I am very familiar with flight termination systems, and even when they work as intended (of which SpaceX has had multiple failures with their AFTS system on Starship) they don’t make the vehicle magically disappear. FTS systems work by terminating active propulsion, venting propellants, or for solid motors cutting the case open to snuff out combustion of the propellant grain, dropping the vehicle into (hopefully) broad ocean area (BOA) within a defined safety corridor and sinking so as to not pose a hazard to shipping. When a vehicle breaks up into a large debris pattern which spreads over a wide area as Flight 7 did, exploding and coming down near Turks and Caicos Islands, closing flight lanes for over an hour and posing a hazard to marine vessels in the area.
Stranger
Right, with bridges, you build thousands or millions of them that fall down. Bridges have been around for a very, very long time, so the True Engineers have had plenty of failures already to learn from. Rockets are much newer, so there aren’t enough failures yet, so you need to make your own failures.
That’s very much not how engineers design bridges. While there are plenty of failed bridges to learn from, none of them are going to help you design, say, the new Gordie Howe International Bridge linking Detroit and Windsor, because there are no nearly identical bridges that have failed to learn from. Engineers design bridges by using math to predict the types and magnitudes of loads on individual elements of the bridge, and then choose material/size of those elements to match the expected load.
Which is exactly what @Stranger_On_A_Train describes SpaceX as using more for the Falcon and less for Starship. Certainly the performance of past bridges can be used to inform the calculations of the expected loads, but that is also the case with past rockets. The fact that there are many more extant bridges to learn from than there are rockets doesn’t mean that careful design work can’t remove most failure modes without flying. SLS made it to orbit on the first go, for example. I wouldn’t want to hold SLS up as a model of development worth following, of course, but there ought to be a happy medium here. Move briskly and break only small things, or some such.
We can list a whole host of problems with SLS development that a change in strategy would fix. Most obviously, the fact we’ve spent 26 billion dollars and a decade and a half on a rocket that still can’t fly.
SpaceX has been developing Starship for a similar length of time, by some measurements, but only if you include the time they used to develop the Falcon 9 and Falcon Heavy. The SLS program hasn’t produced any usable rockets, certainly not reusable ones that are far cheaper to fly than anything else on the market.
What exactly is the problem SoaceX is having that we’re trying to solve by telling them to change their approach? Because it seems to me that they are doing just fine in terms of rocket development.
SLS is a ludicrous waste of money, but “can’t fly” is an odd description of a rocket that successfully launched Artemis I on its first go.
The problem SpaceX is having is aptly described in the thread title. Starship keeps exploding. And not exploding in expected ways, but in unexpected ways. And some of those unexpected ways have resulted in safety issues requiring airline flight delays and diversions. Does SpaceX have to pay for that sort of fallout, or do the airlines just have to eat the expenses?
To expand upon that, while engineers might occasionally be introduced to case studies of notable failures to highlight some particular principle or oversight, they don’t learn how to design and build bridges, or dams, or mechanical systems via some process of trial and error. They start by learning basic principles of mechanics on idealized problems followed by the properties of real world materials and behavior of structural/mechanical components, followed by some grounding in methods of analysis. There is certainly empirical knowledge build into engineering principles but that doesn’t limit the ability to design a new kind of structure or mechanical system, and if someone built a new kind of bridge or dam using modern design knowledge and analysis tools only for it to fail in some way it would be considered to be engineering malfeasance rather than some kind of ‘learning exercise’.
Now, rockets are a bit of a different beast because they are highly dynamic complex systems and experience many loads and conditions which cannot be fully represented with analysis tools or tested on the ground, so a potential for unexpected failure exists even in a system that has flown previously due to a latent design defect or quality control issue. The problem isn’t that SpaceX has experienced failures with Starship but rather how cavalier they are about failures which have turned out to be both avoidable by just applying common sense and good design principles, and have put the public and protected habitats at risk, all in service of the uninformed fantasy of a malignant narcissist and cosplay fascist to establish his own techno-feudalistic empire by ‘colonizing’ Mars.
Yeah, I’m not going to defend SLS, which started out as a proposal Shuttle-derived interim replacement for the cancelled Constellation program but rapidly morphed into a political sop for powerful Congressional interests, and is insanely expensive for an essentially useless flight rate, but it certainly flew on its inaugural launch with only very minor anomalies. I don’t think it is really a fiscally viable flight vehicle nor does it really have a clear purpose beyond exclusively supporting the Artemis program (which also has some pretty nebulous goals), and in general the entire notion of maintaining permanent human presence on the Moon, much less on Mars, is problematic to say the least.
Stranger
I fully concur with this. I’ll add that @K364’s description of software development as “put in a bit of effort and see how it goes” is not at all accurate and far from universal. They appear to be describing a family of different approaches to software development collectively known as rapid application development (RAD) which may be appropriate for some projects (usually smaller ones) but absolutely not appropriate for others. Large software development projects, especially mission-critical ones, require rigorous phases of architecture, system design, and detailed design phases, all with verification and signoff requirements, and all of which must be completed before a single line of code is written.
The problem with Musk isn’t a “programmer mentality”, the problem is he doesn’t understand software development methodologies at all. His demand to see “code samples” at Twitter is very much like hiring an architect to design and oversee the construction of your new house, and handing him a hammer and asking him to drive a nail into a piece of wood so you can assess how “skilled” he is.
I am certainly not a potential customer, but possibly having potential customers comfortable putting their expensive and possibly mission critical payloads on board in the future? Not giving competitors like Rocket Lab or even Blue Origin a chance to catch up, but with ships that don’t explode as often?
Why on Earth would they feel uncomfortable flying on a finished product because a prototype blew up?
Do you feel uncomfortable driving your car because while it was being designed a bunch of that model got crash tested?
Once Starship is complete, and actually goes into service, it will develop a service record for the actual finished product; presumably it will fly a bunch of payload missions before it ever flies an astronaut; and again presumably, it will land unmanned thousands of times before it starts reentering with humans on board.
People should (and IMO will) figure out their comfort level based on the safety record of the finished product.
This somewhat surprises me. My son used to work for ULA, and my understanding was that, while the Delta and Titan launches were pricey, they were extremely (nearly 100%?) reliable. What is your source for the unreliability of non-SpaceX launches, and how early were those failures?
(As I recall, my son’s early dislike for Musk reflected - in part - his impression that SpaceX was exempted from many govt requirements with the aim of creating competition.)
Right, if they were exploding in expected ways, that’d be a big problem. Exploding in unexpected ways means that they’re doing their job in these test flights, which is learning the ways in which things fail.