Hacker News new | past | comments | ask | show | jobs | submit login

An interesting aspect is that NASA gets criticized from both sides. Here Carmack is basically criticizing NASA for not taking enough risks, being too cautious in the meticulous engineering instead of whipping out a saw and trying something. But whenever something goes wrong and there's an inquiry, the inquiry always blames NASA for being too seat-of-the-pants, not doing enough proper engineering and analysis of safety margins, not following procedures to the letter, etc., etc.



In American culture, the death of one person is typically considered unacceptable, and "we will do everything to ensure it never happens again." To date, NASA has flown many more manned missions than its private competitors. Most unmanned missions can have their cargo and vehicle replaced (albeit at great cost), but from the first-world view of "every life is precious," the same cannot be said of manned missions. So there is a fundamental, qualitative difference between the two types of missions and organizations. You can well imagine what will happen each and every time a human life is lost on a private space mission.

Will we ever consider it the cost of doing business? Probably not, except for military missions--and in the context of going to Mars, we might see more of those.


There's a large difference between experimentation and not properly vetting a vehicle containing living things.


"Here Carmack is basically criticizing NASA for not taking enough risks [...]"

I understand your point, but I think it's important to take this in the context of what type of risk is being discussed (i.e., payload-only).

"We got to the point, where, we were scraping by, I mean, we had an operating profit, but it was doing contract work for other people, and I reached the conclusion that we just weren't going to get where we needed to go with that.

There's this tempting thought, that, if you work for contracts people, and you pick the right contracts, you'll be developing things that you wanted to develop anyways, that it will help you towards your goal. [...] It wasn't working for us. We were keeping the lights on, we were building rockets, but they weren't the tasks, the things that we needed to do."

That was about 2 years ago. They got side-tracked. They moved away from their core competency of what they needed to do, and started taking on outside work for what they thought would supplement their efforts, but it ended up moving them away from where they needed to be, and the added process requirements, as John said, "[...] it definitely slowed us down."

Clearly, when you go into human spaceflight mode, you are going to want to have a lot of well-defined, rigorous process in place. However, they were dealing in payload-only scenarios at this point, with entities that knew the "at risk" status of the launches. In John's words:

"They were sort of like, 'at your own risk'... you can put 'em up, you might get your payload back, but there's a good chance we're gonna crash. [...] They knew it was at-risk, and we didn't take their money when we didn't make a successful flight."

Given what they were doing (i.e., payload-only), this is the context in which he was saying that, "[...] NASA loves seeing all this stuff, it gives everybody that's contracting a good set of warm fuzzies to get stuff you hold in your hands on the engineering documents [...]"

I do not know this as fact here, as I am speculating, but it is possible that they were simply in the mode of iterating to their best ability, with the concept of operations being, "Let's rapidly prove what we can do in the payload launch and recovery area, and once we get funding, we can scale up the process and procedure aspects required for human spaceflight."

It would be interesting to hear John's comments on this topic, for sure... but in summary, from the context of his comments, I think his line of reasoning was perhaps, "Why are we taking on all of this contract work and getting slowed down in process for payload-only scenarios, when we could be building, launching, iterating and learning?"




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: