Open to the idea that maybe (just maybe) javascript might not be the way to go at all times for all things 🤯?

Good news - we have SDKs for over 30 different programming languages: https://opencagedata.com/sdks

@nonlinear @sarahjeong.bsky.social

Yes, SpaceX will eventually have a lives-lost incident, and it will be ugly. How the market / investors take it I have no prediction for.

But NASA has had several of those types of accidents over the years, so the waterfall / perfection model isn't immune to them, either. The two shuttle losses were due to bureaucracy that defeated NASA's safety culture, and the Apollo 1 debacle showed that their vaunted safety and technical reviews actually could miss something very important - several things simultaneously, in fact.

I think it's unfair to compare SpaceX's current test-to-failure of Super Heavy and Starship to human-rated missions from anyone. They did the same test-to-failure rapid development with Falcon 9 and Cargo Dragon, leading to Crew Dragon, and they haven't had a life-lost incident yet. They're not deliberately testing-to-failure with humans on board.

#Apollo1 #Shuttle #Columbia #Challenger #NASA #fatality #astronaut

@sarahjeong.bsky.social

Yeeaaa... it's a different approach.

(Don't read this as a defence of Musk, he's a turd, but SpaceX has competent technical people below their chimpanzee-on-a-string PR person)

NASA's traditional approach was to basically achieve perfection of design and manufacturing before trying to launch anything. Look at every possible failure mode of every component, down to the tiniest screw or wire or bit of plastic. Keep redesigning parts until you eliminate all failure modes that you don't have triply-redundant backups for. Test the living snot out of everything on the ground, in the lab. Have massive technical and safety reviews to ensure nothing was missed, anywhere.

It worked about as well as anything could, but it was extremely slow, bureaucratic, and above all incredibly expensive. Tons of rework when issues were found meant having to go back 3 steps to change something, and then redo the massive amount of work that had been done since then to make sure no new failure modes were possible, etc.

SpaceX is doing things differently - #iterative design. You design, build, #integrate, and #test-to-failure as often as possible to learn where the weak spots are -- you then rapidly iterate when you find the problems. "Rapid Unscheduled Disassembly" is an expected part of the process - it's how you learn the limits of what you've built, where the problems are.

Neither one is "the right way". They both work.

#IterativeDevelopment