Before You Optimize, Delete

There's a Tesla story in The Book of Elon that I keep coming back to. The factory had a fiberglass mat sitting on top of every battery pack. Someone had been told to make installing it faster. They built robotic arms that placed the mat in seconds. They got the cost down. They sped up the line again. Months of work.

Then somebody finally asked why the mat was there. The battery team thought it was for noise. The noise team thought it was for fire safety. Nobody actually knew. They tested without the mat. The car was fine. They deleted the part and the two million dollars of robotics that lived above it.

This is the part of Elon's "Algorithm" I most underrate. The order is: make the requirement less dumb, try to delete the part, simplify, then accelerate, then automate. The order is not optional. The cost of getting it wrong is what the fiberglass-mat team paid: months of careful optimization on something that should never have existed in the first place.

I've done this exact thing. Refactored a function I should have deleted. Sped up a build for a project I threw out months later. There are a lot more like that. The reason it happens is that optimizing is satisfying. It feels like productivity. The numbers go up. Deleting feels like admitting yesterday was wasted.

The trap is that the better you are at the lower steps, the more expensive it is to skip the higher ones. Automating something is a way of committing to it. Once you've spent a quarter shaving milliseconds off a query, nobody on the team wants to ask whether the query needed to exist. The optimization becomes its own argument for keeping the part.

The Algorithm in reverse is just discipline against that. Before "how do I do this faster," ask "do I need to do this at all." Then find somebody alive who can actually name the reason it should exist.

Musk has a tell for whether you're skipping the step. If you aren't adding things back about ten percent of the time, you didn't delete enough. A team that never re-adds a deleted part has only been deleting the obvious junk. Real deletion is supposed to feel slightly reckless and occasionally wrong, because that's how you find out where the real edges are.

The version of this for my own work is small. Before I plan or build anything, I want to know that the thing exists for a reason somebody alive can defend. If the answer comes back as "I think the noise team thought it was the safety team's call," delete it.