Elon's 5 step process for Engineering Stuff

... and some other quotes..

A couple days ago, Tim Dodd a.k.a. Everyday Astronaut started publishing a three-part tour of SpaceX's Starbase facility (the one where they're assembling Starships)... with Elon Musk as the tour guide. So far, two of them are out, each about an hour long, and they're totally worth a watch if you're interested in space exploration or... engineering, really.

Part 1, Part 2 (... both youtube links).

In particular, he mentioned a 5 step process every design should go through... which I hereby summarize. Because why not. And also, I do think it's also super useful for software engineering... especially because bad design is even less apparent first when being done to software (but no less detrimental later).

1) make your requirements less dumb.

"... it's particularly dangerous if a smart person gave them to you, since you might not question them enough."

As a practical example: who is it actually coming from? Apparently, at SpaceX, they have a rule that requirements need to be owned by a single person, not a department... that way there is a lot less chance for something to be implemented just because it got stuck on some list somewhere and no one thought of throwing it out.

2) try very hard to delete the part or process.

"... if you're not occasionally adding things back in, you're not deleting enough. The bias tends to be very strongly towards 'let's add this part or process in case we need it', but you can basically make in-case arguments for so many things..."

Yet again, they're designing a rocket. Parts have actual mass; by getting rid of them, you can also save on fuel, engines, etc. With software, it's less obvious, but more lines of code means more bugs, and more complexity to interface with later. This is why test-driven development makes sense: if you're about to write code that you can't even make up a test case for, maybe you shouldn't be writing it?

3) simplify or optimize.

"... it's only the third step!"

... and one of my favorite quotes from the entire thing:

"The most common error of a smart engineer is to optimize a thing that should not exist."

His argument is along the lines of... all throughout e.g. school, you try to solve questions, not getting rid of them or trying to answer different questions. And yet, in the real world, this doesn't always lead to great things.

4) accelerate cycle time.

... with the obvious caveat of... don't actually do this until you've done all the previous steps.

... most of "modern" software development is really bad at this, compared to how flexible of a medium software itself is. Coming from Lisp-Land, the concept of "compilation times" is somewhat ridiculous, let alone compiling the very same thing a gazillion times (... looking at you, C++ headers). At least we seem to be getting slightly better at it on a larger scale (agile vs. waterfall).

5) automate.

"... now, I personally made the mistake of going backwards on all five steps. Multiple times."

He had a cool example: an insulation mat above the Model 3 battery pack, which was a particularly slow step in the manufacturing process. They started with trying to speed up the robot doing the actual work... then optimized the amount of work that actually had to be done (less glue!), only to realize later that the part itself shouldn't have existed: the battery safety team thought it was for soundproofing, meanwhile the noise and vibration team was pointing at battery safety reasons.

(In the end, they removed the entire thing, without noticeable effects.)

In software, we're excellent at automation; Continuous Integration is a thing, and we keep building build systems sometimes exceeding the complexity of the thing being built. And yet... this is sometimes the easy part. Keeping it simple... is harder.

... comments welcome, either in email or on the (eventual) Mastodon post on Fosstodon.