Comment by toolz | Hacker News Reader

Comment by toolz | Hacker News Reader

Parent Full thread

To that example though, is NASA really the pinnacle of achievement in their field? Sure, it's not a very competitive field (e.g. compared to something like the restaurant industry) and most of their existence has been about r&d for tech there wasn't really a market for yet, but still spaceX comes along and in a fraction of the time they're landing and reusing rockets making space launches more attainable and significantly cheaper.

I'm hoping that example holds up, but I'm not well versed in that area so it may be a terrible counter-example but my overarching point is this: overly engineered code often produces less value than quickly executed code. We're not in the business of making computers do things artfully just for the beauty of the rigor and correctness of our systems. We're doing it to make computers do useful thing for humanity.

You may think that spending an extra year perfecting a pace-maker might end up saving lives, but what if more people die in the year before you go to market than would've ended up dying had you launched with something almost perfect, but with potential defects?

Time is expensive in so many more ways than just capital spent.

SpaceX came along decades after NASA’s most famous projects. Would SpaceX have been able to do what they did if NASA hadn’t engineered to their standard earlier on?

My argument (and I’m just thought experimenting here) is that without NASA’s rigor, their programmes would have failed. Public support, and thus the market for soace projects, would have dried up before SpaceX was able to “do it faster”.

(Feel free to shoot this down: I wasn’t there and I havn’t read any deep histories of the conpanies. I’m just brainstorming to explore the problem space)

So I wonder if SpaceX has a lending library of all of the relevant (quality-related) NASA documents, printed out on dead trees. For light lunchtime reading.

The fallacy here is that you're assuming that doing things right takes more time.

Doing things right takes less time in my experience. You spend a little more time up front to figure out the right way to do something, and a lot of the time that investment pays dividends. The alternative is to just choose the quickest fix every time until eventually your code is so riddled with quick fixes that nobody knows how it works and it's impossible to get anything done.

It's tough to sell this to leaders and managers that there could be more benefit to quality and stability at the cost of cutting scope and losing a few oh so indispensable features. But their incentive is to dream up imaginative OKRs and come up with deadlines to show visible progress and justify their roles until the next quarter.

Reply on news.ycombinator.com