Elon Musk's Development Algorithm

So if you haven't seen it yet, Tim Dodd (Everyday Astronaut) did a fantastic interview with Elon Musk as things accelerate to the launch of the most powerful rocket ever built over at Starbase, TX(video). Among many other things covered in part 1 of a 3 part series that the interview has turned into, there is a fascinating algorithm that Elon talks about in a bit of depth about design and manufacture that is one of the best distillations of agile practice I've ever seen. It's literally a set of guiding principles to fast, iterative development refined by one of the living masters of agile which is general enough to apply equally to software or manufacturing, physical or digital development. In a period in time when "agile theatre" is a movement of no small momentum this is a welcome breath of fresh air and insight into how to move fast and break things so you can build better things in the end.

So Elon explains this really well with lot's of anecdotes and self deprecation, but here's my attempt to paraphrase and simplify the algorithm.

1. Make your requirements less dumb.
   • All requirements are dumb, make yours less so.
   • Also, all requirements must have named human owners who take responsibility for them.
   • Smart people are no exception to this rule and their requirements are more suspect for it.
2. Delete the part or process.
   • If you are not forced to add back in at least 10% from time to time, you didn’t delete enough in the first place.
3. Optimize the part or process.
   • After step 2 so that you are not optimizing a step or part which should be deleted.
4. Accelerate cycle time.
5. Automate.

So the first step is great as it admits to a fundamental flaw of gathering requirements. Making requirements is hard, like predicting the future hard, and nobody does it well. No matter how smart you are, or how many time you've done something before, your requirements are stupid. This not only concedes to a truth, it opens design up to the endless possibility of improvement. If the original requirements are dumb, then there is always room for improvement.

The second step is probably the most important functionally even if the first is the most important ideologically, strip everything down to the minimum viable product. And it's ruthless, strip it down until it breaks and is unworkable and things need to be added back in, or you are not doing it right. This is kind of like good security, tighten it down until it's unworkable then ease back a little bit. You can always iterate later to add features, but focus on the minimum needed this time (next time too, but we don't talk about that).

The third step is the great destroyer of projects, no matter how important it is, optimization needs to be after the deletion phase. And often optimization should never be a first iteration task, things need to work first before you can consider optimizing them. It should be a well known truth that premature optimization is poisonous to development and engineering, but it's always so tempting to do when presented with a problem or task. And maybe most importantly, optimizing something that doesn't even need to exist is pure waste so this step has to exist after trying to remove everything non-critical.

The fourth step helps define a difference between optimization and acceleration which is a really good way to break up the tempo problem. In computing systems it's often tempting to throw bigger, faster hardware at a problem, but this is hit or miss in effectiveness if you don't know the problem well enough to optimize it first. Where optimization might be to aerodynamics and acceleration might be a bigger engine with both these are two parts of the same problem that should be distinguished and tackled independently but in series to create a better performing whole.

And finally automate, which is often a well known initial goal, but if you don't understand step one and go through the process on steps 2 through 4 you probably don't understand enough to automate correctly in the first place.

If you're wondering why I called this a "move fast and break things" approach, please review step 2 again.