Slow software
Software has spent two decades optimizing for speed. But speed was never the goal — it was a proxy for something else. What if we optimized for pace instead?
There's a paragraph in a 2019 essay by Robin Sloan that I think about constantly. He describes a piece of software as having a tempo — a speed at which it wants to be used, a rhythm it imposes on your attention. Most software, he says, wants to be used fast. What if some software wanted to be used slowly?
Speed as default
For twenty years, the performance conversation in software has been one-directional: faster is better. Load times, render times, interaction latency, time-to-first-byte. Every millisecond shaved is a victory. This is not wrong — slow software that should be fast is a failure. But it's incomplete.
Speed is a proxy for respect. When Google makes search results load in 200ms, they're saying your time matters. When a productivity app launches instantly, it's saying get back to work. The problem is that respect and speed are not always the same thing. Sometimes respect looks like pausing.
Tempo vs. speed
A tempo is not a speed — it's a relationship between events. A ballad and a dance track can both be at 120 BPM, but they feel completely different because of how the events are spaced within each beat. Software has tempos too:
- Email has a slow tempo. You write, you wait, you reply. The gaps are the point.
- Chat has a fast tempo. Short messages, quick responses, constant presence.
- A notebook app has a variable tempo. Sometimes fast capture, sometimes slow reflection.
When we design, we rarely ask what tempo the software wants. We default to fast — infinite scroll, real-time updates, push notifications, always-on presence. But some of the best software experiences I've had were deliberately, almost defiantly slow.
Not every tool needs to respond instantly. Some tools need to give you time to think.
Designing for pace
I don't mean artificial loading delays or skeuomorphic animations. I mean designing the structure of the interaction to accommodate thought: requiring a confirmation before publishing, showing a preview before sending, giving a summary before committing a destructive action. These aren't speed bumps — they're breath marks in the score.
The best software doesn't just get out of your way. It knows when to step aside, and when to stand still with you.