A 2019 essay says fast software is a proxy for trust — the thread asks whether fast means correct or just risky

The thesis: slowness is a smell

In this 2019 essay, Craig Mod argues that software speed is "the most valuable, least valued asset" in application design — and that responsiveness is really a proxy for overall engineering quality and trust. When a text editor struggles with a 5,000-word document, he doesn't read it as a minor annoyance; he reads it as a warning sign that sync could fail or data could be lost. Fast tools let you enter flow; slow ones break it. His examples are concrete: nvALT opening instantly against Photoshop taking 3–5 seconds just to load an export dialog, Figma delivering near-native speed inside a browser, and his own defection from Google Maps to Apple Maps purely over responsiveness, despite worse data.

Reposted years later, the thread mostly agrees with the feeling and then complicates the logic in a way the essay doesn't.

Is fast a proxy for correct — or a source of risk?

The sharpest addition splits Mod's proxy in two:

"If the software is fast as a byproduct of being simple, that tends to align with correctness. If it is fast because it is optimized, then that does not align with correctness, because optimizing something that works only adds risk." — the creator of the TXR programming language

A second voice pushed back on speed-worship from the user's side — what you're optimizing is time, not milliseconds:

"What matters is how much time it saves. A good WYSIWYG editor will run circles around the fastest text editor. Even if WYSIWYG is a bit slower to open." — a commenter on speed versus time-saved

And a web developer turned it into a concrete rule of thumb — ship the data, skip the round-trip:

"if a 2MB dataset will make a search/select bar return results instantly instead of having to roundtrip an API, just send up the whole dataset … After gzip it's nowhere close to 2MB anyway. Also, I think suspense is an anti-pattern now." — a developer on avoiding the network round-trip

The distinction worth keeping

Mod's instinct — that a laggy tool is telling you something about its makers — holds up. The thread's refinement is what makes it usable: speed earned by doing less is a real quality signal, and speed bolted onto something that already worked is a place bugs come from. So the takeaway for anyone building isn't "make it fast." It's "make it simple, and let fast be the byproduct" — because the version where you chase speed for its own sake is the version that quietly stops being correct.