SpaceX wins $440M contract with NASA to develop Space Shuttle successor

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.

This is the sort of thing where you need to be careful with what you infer, the the sort of thing that often causes engineers to be overconfident in performance and reliability estimates.In reality, they're doing some very initial experiments in vertical landing with a view towards exploring reusability. That is different to your implication that reusability is a done deal.

> They come from extensive simulations and tests, which are then extrapolated. It's not the same guarantee as running thousands of end-to-end missions, but it's better than you imply.

And that's the problem. Notice you're talking about man rated 'parts' and I'm very deliberately not. Many of the mission failures or anomalies in launch vehicles so far have come from parts that work fine on the bench as individual subsystems. It's the lack of full-scale, realistic tests of complete systems that cause problems. There's just not the money for it nowadays. For example, Orion's crew vehicle had budgeted 2 aeroplane parachute drop tests. Apollo's landing module had over 230. Interestingly, they recorded anomalies on over 210 of those.

As for simulations, well one of the catch-phrases in the rocket engine business is 'plumbing never leaks in simulations'.

As for extrapolation, as a datapoint related to a field I have worked in (parachutes for space systems), quite a few of the high profile parachute failures were colloquially summarised as 'they extrapolated without a license'. All the Mars landers the USA have landed so far have used disc-gap-band parachutes of the same design and size that were explored in a set of very expensive and extensive tests performed at high altitudes for the 70s Viking Lander. It's called the 'viking box' and people at JPL know you do not just 'extrapolate' out of it because they've seen what happens when smart, well intentioned engineers do. That's why they called it a box :)

Going back to simulation for a moment, I am familiar with the state of the art of parachute simulation (and fluid-structure interaction simulation in general), and so are they people in charge of the space missions, and that's why they stick to the Viking box. We can barely match that viking data in sims, let alone start wondering out of it into unexplored territory.

Finally a little anecdote from Charles 'Chuck' Lowry, the guy who designed the apollo landing systems, about testing. On Apollo 15 reentry, one of the 3 parachutes failed, the first and only recorded failure of an apollo chute during operations. It was traced back to being because the landing module thrusters had vented their fuel out before landing, but this had ignited on the still hot nozzles on the way out, causing a load of burning fuel to go fly up into the chute and destroy it. Thank god, he said, that it only caught the one and not a second one, else it could have ended very badly.

The parachute system tested perfectly, and the thrusters performed admirably during their entire qualification program and all previous flights. But the combination of these two systems, under real conditions, interacted in such that the consequences were a significant risk to life. 'You ain't tested it till you've tested it', he said.

HN is full of similar examples of outages of things like AWS due to an interaction of failures of parts, systems, and bob the technician not putting the circuit breaks back in exactly the right place after routine maintenance. The space of possible failures rises exponentially with the number of parts, when you consider all the ways they can interact. It's a hard problem to solve and the people at the top are under no illusions about the reliability numbers, they're made for congress and journalists.

IIRC, it takes 9 km/s of delta-v to get from ground to LEO. LEO is only orbitting at ~7.7 km/s, though, so you can save at least 1 km/s of fuel.

As others have said, schemes like Stratolaunch or SpaceShipOne also get horizontal velocity from the mothership.