Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm not saying you should hack a sub from a scrap metal and just use it as is (which seems to have happened here). But you can rapidly iterate on your project to first make it functional and then gradually improve its reliability.

What matters is not the process, but the result. For example, SpaceX are using iterative approach in their design and they now have the most reliable rocket in history.



I'm not sure of your point here. You claim that SpaceX's process was an iterative one which lead to the 'most reliable rocket in history', but state that the process does not matter.


As I see it, there are two approaches: "NASA" approach and "SpaceX" or "Silicon valley" approach. In "NASA" approach you are building the system bottom-up ensuring the reliability on each level. In "SpaceX" approach you build a barely functional system as fast as you can and then iterate to improve reliability (and other characteristics).

The top comment in this thread seems to imply that "NASA" approach is inherently better, especially for safety-critical applications. My view is that from the point of view of safety, the approach doesn't really matter and what matters is the results, i.e. reliability. At the same time from the point of view of development velocity iterative approach is clearly better.

In case of the sunk submarine, it seems that the company followed iterative, "SpaceX" approach, but they didn't actually iterate enough to make their sub seaworthy.


> My view is that from the point of view of safety, the approach doesn't really matter and what matters is the results

But you won't know the 'results' until you have a catastrophe and can do a post-mortem and find out where you went wrong. The approach does matter because one approach is 'let's do everything we can to prevent the catastrophe'. I mean, the approach is safety.


Yeah. IMHO this thing should have gone unmanned to the bottom a gajillion times, and exposed to all variety of stressors, before a paying passenger was on board. Maybe that's not possible? Maybe it was in fact prohibitively expensive? I'd love to hear why I'm wrong, but it seems wild to me that paying passengers are along for a ride after only really a handful of successful trips in this thing, ever.


SpaceX has explicitly very different approaches for crewed and uncrewed crafts. Uncrewed rockets are pushed to the limit over and over and over again, to drive innovation and thoroughly test them. As soon as a single person is on board, their margin for error goes to zero.

I'd argue this is in fact superior to NASA's approach, which rarely allows for uncrewed testing (and spectacular RUDs), leading to technological stagnation and catastrophic organizational risks. (i.e. internal resistance to doing anything about the O-ring problem on Challenger, even though they had been alerted about the potential issue).


Your first examples weren't rockets, but search engines, video hosting platforms and chatbots.

Second, it's all very well "iterating until you succeed" but that's not a good approach when live humans are involved in the iterating. "Move fast and break things" is not the same as "move fast and break people". Space X, after all, had to prove a certain level of reliability before NASA let them fly people to ISS.


"Most reliable rocket in history" that's a pretty bold statement when they have so few launches compared to Soyuz or Atlas V




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

Search: