Elon's 5 Rules for Engineering as they apply to software development

On Friday 2021-07-30, Elon Musk conducted a long interview and SpaceX facility tour with photographer-turned-YouTuber Tim Dowd aka "The everyday astronaut." Tim put together three videos of the interview and tour that are highly entertaining and worth your time to view, whether or not you care about rockets & space.

One part of the interview with which I was very impressed is Elon's description of his five step engineering process.  Tim posted his notes from the interview on his website.  Here is an excerpt:

Musk overviewed his five step engineering process, which must be completed in order:

1. Make the requirements less dumb. The requirements are definitely dumb; it does not matter who gave them to you. He notes that it's particularly dangerous if an intelligent person gives you the requirements, as you may not question the requirements enough. "Everyone's wrong. No matter who you are, everyone is wrong some of the time." He further notes that "all designs are wrong, it's just a matter of how wrong."
2. Try very hard to delete the part or process. If parts are not being added back into the design at least 10% of the time, not enough parts are being deleted. Musk noted that the bias tends to be very strongly toward "let's add this part or process step in case we need it." Additionally, each required part and process must come from a name, not a department, as a department cannot be asked why a requirement exists, but a person can.
3. Simplify and optimize the design. This is step three as the most common error of a smart engineer is to optimize something that should not exist.
4. Accelerate cycle time. Musk states "you're moving too slowly, go faster! But don't go faster until you've worked on the other three things first."
5. Automate. An important part of this is to remove in-process testing after the problems have been diagnosed; if a product is reaching the end of a production line with a high acceptance rate, there is no need for in-process testing.

Additionally, Musk restated that he believes everyone should be a chief engineer. Engineers need to understand the system at a high level to understand when they are making a bad optimization. As an example, Musk noted that an order of magnitude more time has been spent reducing engine mass than reducing residual propellant, despite both being equally as important.

In software development we may be able to adapt the principles of each step in this process to improve our development lifecycle.  Let's look at each step:

Make the software product requirements less dumb. The requirements are definitely dumb; it does not matter who gave them to you. It's particularly dangerous if an intelligent, charismatic, articulate person gives you the requirements, as you will not challenge the requirements enough. Everyone is wrong. No matter who you are, everyone is wrong some of the time. All designs are wrong, it's just a matter of how wrong.  Some loud minority of customers or stakeholders of your software will prioritize useless, hazardous, or destructive requirements and fail to communicate or prioritize requirements for the core purpose of your software.

Try very hard to remove objects, components and features. There is no code with fewer bugs than no code. If components are not being added back into the design at least 10% of the time, not enough of your design was deleted. Human nature biases everyone very strongly toward solving problems by adding complexity. We must constantly try to simplify. Additionally, each feature requirement must come from an individual who has evidence for her need, not a title or a department, as a department cannot be asked why a requirement exists, but a person can.

Simplify and optimize the software design. The most common error of a smart engineer is to optimize something that should not exist. Premature optimization is the root of all evil.

Don't go faster until you have completed the first three steps; then accelerate.

Refactor, optimize, simplify  Your continuous integration, deployment, and test suites are too big, complicated and take too long.  Keep integration tests for the Beyoncé rule and hold on to most negative tests for corner cases or data races; consider trimming positive "coverage" tests and speed up or delete your slowest tests.  Automate wherever possible.