Stacking Tolerances

Tobi Lutke, the founder of Shopify, tweeted this recently:

For software engineering, my sense is that the phrase “premature optimization is the root of all evil” has massively backfired. Its from a book on data structures and mainly tried to dissuade people from prematurely write things in assembler. But the point was to free you up to think harder about the data structures to use, not leave things comically inefficient. This context is always skipped when it’s uttered.

Not all fast software is world-class, but all world-class software is fast. Performance is the killer feature.

I don’t know that “performance is the killer feature” but I do think that if you take too casual an approach to performance, and chalk up detail work to “premature optimization” you’re likely to end up with an engineering culture that doesn’t realize the importance of performance until it’s too late.

Those seemingly insignificant “meh it’s fine, premature optimization is bad” decisions stack up like tolerances in a mechanical system, gradually eroding the efficiency and reliability of your software and even the ability of your team to get shit done effectively.

It’s insidious because it’s not just about app performance. It’s actually about the culture of your engineering team. The habits you’re building. Even the way you think about your work. The overcorrection impacts everything you do.

Your test’s that were slightly annoying when they took ~10 minutes to run are now taking ~30 minutes, and deploys are taking forever.

That sorta slow query in that one untested method that was fine for that one page that no one really uses? It’s now load bearing and in the call path for your most visited pages.

That runbook for that service that didn’t get updated because “not much changed really, and I have a feature to build” is now failing over in a way that’s causing problems, and no one is sure why.

You’ve taken a laissez-faire approach for so long that all your “meh ship it, premature optimization is bad” choices are stacking, and suddenly, your app or service is slow. When you finally realize that your performance is a problem, you’re not just dealing with one or two things that need to be optimized. You’re dealing with a mountain of technical debt that’s been building, and an engineering culture with a bunch of bad habits.

Set a reasonable high bar for performance and tolerance for jank and then stick to it. Don’t let the “premature optimization is bad” mantra be an excuse for not thinking about performance. Build a culture that values performance and reliability not for their own sake, but because they’re the foundation of a good user experience and a maintainable system.