Until you have actual experience with the weird stuff that goes wrong in the field, you do not really know what is going to go wrong. And the more complicated the system is, the more true this fact is.

Incidentally I had the opportunity at one point to ask the first software developer ever hired at SpaceX whether he would trust his own software. His answer was enlightening, I wouldn't want to put my life in the hands of someone who trusted his own software, so I'm going to say no.

There is always SOMETHING that can go wrong. You want the person who created your safety system to be a paranoid freak. And you have to pray that they didn't miss something. You hope and pray for the best, but until you have actual data, you don't know how it is going to turn out.

Here's how the Falcon 9 + manned Dragon would abort: the capsule would separate from the launcher as the escape rockets fired, meanwhile the launcher's engines would be shut down (cutting off thrust). The capsule would then coast through the atmosphere until it slowed down then deploy its parachutes when it had slowed down enough and float to the surface.

Here's one abort mode for the space Shuttle: the Shuttle continues to fly until the SRBs have burned out (there's little choice about that) and jettisoned, then the orbiter rotates 180 degrees so that it is thrusting against its direction of travel, the SSMEs continue to run until the forward momentum is cancelled and the vehicle is headed back toward the launch site, then the SSMEs are shut down and the ET jettisoned, the orbiter then glides to an unpowered landing at the KSC landing strip.

Or, how about this one: if the Shuttle's SSMEs cut out during flight then the orbiter rides along until the SRBs burn out, then they and the ET are jettisoned, the orbiter glides a bit until it slows down, then a hatch is opened and a rail is extended out of the hatch, the crew then individually bail out of the vehicle as it is traveling several hundred mph by sliding along the rail (which allows them to avoid hitting the wing) and deploy their individual parachutes, they land in the ocean and are recovered by a search-and-rescue team.

That's complicated, the Dragon/Falcon is utter simplicity.

Given that the shuttle's SRBs were "once they start, they don't stop until they're empty", sometimes more complicated is a good thing.

> Until you have actual experience with the weird stuff that goes wrong in the field, you do not really know what is going to go wrong. And the more complicated the system is, the more true this fact is.

I'm fairly certain SpaceX has been employing people with actual experience.

> Incidentally I had the opportunity at one point to ask the first software developer ever hired at SpaceX whether he would trust his own software. His answer was enlightening, I wouldn't want to put my life in the hands of someone who trusted his own software, so I'm going to say no.

That's why they probably have more than one developer plus QA team.

> There is always SOMETHING that can go wrong. You want the person who created your safety system to be a paranoid freak. And you have to pray that they didn't miss something. You hope and pray for the best, but until you have actual data, you don't know how it is going to turn out.

True, certainly, but the same argument can be used on cars. Things still go wrong, but we can also safely say they're safer than a car from the 1970s.

Yet even with cars, even with the fact that they have experienced designers, when you build a new car model and put it out, you don't always get it right. You don't know what you did wrong. Which is why we regularly see safety recalls issued on cars - even from the best companies - for everything from software updates to changing the floor mat.

Until you see a model in use in the real world you simply don't know. Even if you have experience on a related model, there is the possibility of something new going wrong. Something you would have never thought of. Like the gas pedal getting stuck on a floor mat.

You take into account everything you know about. You run every feasible test that you think is useful. You run tests in simulators, on isolated components, on the whole model. You review and double review your work. You set up safety checklists to verify everything on the spot. But until you actually see the accident data, you don't really know whether you missed something important.

This is true for cars. It is true for airplanes. It is true for rockets. But the critical differences are that rockets are inherently more dangerous, it isn't feasible to do the same number of tests on them, and we don't get nearly as much accident data.

You have to options:

Option 1: Ride in a car with a single button labeled "press to start engines, you will not be able to stop until they run out of fuel". This car has been driven about a hundred times.

Option 2: Ride in a car with a "start engine" button and a "stop engine" button, plus a throttle. This car has been driven several times plus extensive testing on the ground.

"Option 2 is a safer setup" seems like a fair statement.

I like that. There are a million ways you can answer a given interview question that will cost you the job, but there are also a few ways you can make me end an interview and make you an offer on the spot. Under the right circumstances, that answer would be one of those.

And you have to pray that they didn't miss something.

I don't have to do any such thing.

Source? If you're talking about F1-003, you're incorrect. If you're talking about something else, I'm interested.

And yes, I had remembered it wrong from when I watched it a few weeks ago. I remembered the bit about dropping below sea level pressure, but not the rest of the cascade.

A great lesson for software devs.

But I've since learned that it is true in areas far from software.