🗑️Deleting things.

Originally published on LinkedIn

I’ve been captivated by an interview with Elon Musk giving a fan a tour of Space X’s starbase facility. He can be a divisive character, but can’t argue with the results his companies are achieving, so bear with!
30 mins in, Elon explains a 5-step process that I believe relates to software delivery as much as rocket manufacturing. It's part of a passionate message that manufacturing, and not design is the hard part. Their rocket designs are just iterations of what’s gone before, but, nobody has figured out how to build 1000 rockets quickly and cheaply.
With software, building an API or app is easy. Building and operating 100s of them - hard. A massive part of my job these days is working with teams to delete waste and complexity out of our systems, so to hear how Tesla, Space X and Solar city do it was very valuable.

The video (1 of 2) is well worth a watch if you’re into the challenges of space exploration, but if you’re tight on time, here’s the process:

1️⃣ Make your requirements less dumb.
This is particularly dangerous if a smart person gave you the requirements because you might not question them enough. Also, a requirement or constraint must come with a name, not a department because ‘you can’t ask the department, you have to ask a person’ They must take responsibility for that requirement. For example, an intern two years ago came up with it off the cuff, and no one still agrees with it.

2️⃣ Try very hard to delete the part of the process. 💡
If you are not occasionally adding things back in, you are not deleting them enough. Look out for “let’s add this part or step in case we need it”

3️⃣ Simplify or optimise.
Make sure you have first done steps 1 & 2. An engineer’s most common error is to optimise a thing that should not exist. We have a mental straight-jacket on once the part or process exists.

4️⃣ Accelerate cycle time.
If you’re moving too slowly, go faster but only if you’ve done 1,2 & 3.

5️⃣ Automate.
Make sure you’re investing in automating the things we definitely need and have optimised.

An example of the process in the tour is deleting the components to fold Starship’s enormous grid fins. We’ll soon see if it still works ok 🤞. Back on earth, I see places to apply this process all the time:

Network clunk:
System designs where there is a load balancer put in front of a lambda - We’ll put a balancer in front of a thing that has its own sophisticated traffic management system in case x,y, or z might happen. Throw it out, and test the scenarios - does it still work?

Over-queuing:
We run a queue and then a function will consume off the queue. Sure, that used to be the way to do things, but now there is asynchronous invoke which probably does what you need (on a queue you don’t have to care about).

Flaky tests:
That end-to-end test that everyone on the team hates and distrusts - do we need it or is it just trying to compensate for not enough lower-level tests?
#serverless #devops

The Starbase tour (1 of 2) where Elon Musk talks about their approach to requirements