The performance culture in software is, on the whole, a good thing. Pages should load fast; interfaces should respond instantly; nobody should wait. But somewhere along the way "fast" stopped being a means and became an end, and a quiet cost got hidden in the bargain.

What speed optimizes for

Speed optimizes for the first interaction. It optimizes for the moment of arrival, the click, the scroll. These matter — they matter a great deal for retention, for commerce, for the simple dignity of not wasting someone's time. But they are not the whole of an experience.

A lot of software that loads instantly is also software that is shallow. The interface is fast because it does very little. The search is snappy because it indexes nothing interesting. The response is immediate because the computation is trivial.

The fastest software is software that doesn't do anything. This is not a goal.

What slowness can protect

There is a class of value that only emerges when software is allowed to take its time. A search that spends three seconds but returns a genuinely thoughtful result is better than one that returns ten mediocre ones in fifty milliseconds. A build that runs for a minute but catches a real bug is worth more than an instant build that catches none.

Slowness, in the right places, protects:

  • Depth. Computations that actually matter — type checking, real analysis, proper search — take time. Pretending otherwise produces shallow imitations.
  • Durability. Software built to last is built differently from software built to ship. The latter optimizes the demo; the former optimizes the decade.
  • Calm. Interfaces that respect attention rather than demanding it are, almost by definition, less twitchy. They are also, I would argue, more humane.

The honest version

I am not arguing for slow software as a virtue in itself. Lag is still lag, and there is nothing noble in a spinner. The honest version of the argument is narrower: not everything should be optimized for the first interaction. Some software should be optimized for the hundredth, and that requires a different set of tradeoffs — ones the performance culture is bad at seeing.

A reading app should let you find a passage fast, but it should also let you stay with a passage without buzzing at you. A notes tool should open instantly, but it should also be structured so that ten years of notes remain navigable. The fast part and the slow part are both real; the culture only celebrates one.

A small test

Here's the test I've started applying to my own tools: would I be happy using this in five years? If the answer is "only if it hasn't changed," then I've optimized for the demo, not for the duration. The tools I keep are the ones whose value compounds with use — and those, almost without exception, are the ones that were allowed to be a little slower in the places where slowness is the price of substance.

Defend the slow parts. They are where the depth lives.