[WIP] Elon Musk - What is required for excellence is more silly than you think
Elon Musk “silly rules”
Following the order of the rules is key
A big error that Elon confess to have made, multiple times is to do the steps backwards. He did it for example in some components of the Model 3: Automated, accelerated, optimizing/simplify and then deleted
- Step 1, make your requirements less dumb
- Step 2, delete the part or process step
- If you are not deleting a part or process step at least 10% of the time
- Step 3, simplify or optimize. Don’t optimize a thing that should not exist.
- This is the 3rd step, is a common error of a smart engineer is to optimize a thing that should not exist. This is because the convergent logic we learn in school, about “just answering the question”, you are not allowed to tell a professor “your question is dumb”
- Step 4, accelerate cycle time (Iterations). If you are moving to slowly, go faster. But don’t go faster till you’ve worked in the previous 3 steps first
- Step 5, automate
- Step 6, you really want everyone to be chief engineer, that means, people need to understand the system at a high level to know when they are making a bad optimization.
Step 6 bad decision example will be to have people reducing the rocket engine weight (a lot of time), instead of getting rid of the residual fuel on landing, so the rocket lands and have still a ton of fuel that can be optimized (falcon 9 still has this problem)
And some readings about testing a production line
- Another mistake that has to happen in production is too much in-process testing. So when you were first setting up a production line, you don’t know where things are breaking. You don’t know where things are breaking, so you’ll test like working process at various steps and ‘cause you wanna isolate where’s the mistake occurring? So a very common issue with production lines is to not remove the end process testing after you diagnose where the problems are. So basically if you have like a very high acceptance, like if things are getting to end of line testing and are passing, then you don’t need to do in-process testing.
This may be a point to consider in sofware development, unit testing will be in-process testing and end of line testing will be integration testing. But in software in-process testing has a ton of sense since multiple persons will vary the “production line”, and a production line (hardware) will not be updated constantly
- And so you just really wanna move things pretty much, almost always to just test at the end line, and that’s it.
My take is that unitary testing applies if it does not slowdown the development, so integration test does if doesn’t slowdown deployments.
Unknown Risks and Iterations
-
And obviously you guys did that with Starship, big time with 8, 9, 10, 11, 15 was like, let’s just get it out there, see what works, see what doesn’t and iterate, you know?
-
Yeah, and if you look at like the various reasons, like why we blew up Starship is like, and you looked at the risk list, none of the reasons that blew up are on the risk list.
-
It was like, no, maybe you can argue like, one of them maybe was on somebody’s risk list, but it wasn’t brought up beforehand.
-
There’s a crazy amount of new technology happening here and it’s all evolving simultaneously, we need to iron out like the unknowns sort of thing.
Applied to IT, the amount of technology for each deployment, (OS, network, kernel, software, …)