Software that’s speedy usually means it’s focused. Like a good tool, it often means that it’s simple, but that’s not necessarily true. Speed in software is probably the most valuable, least valued asset. To me, speedy software is the difference between an application smoothly integrating into your life, and one called upon with great reluctance. Fastness in software is like great margins in a book–makes you smile without necessarily knowing why.
…Speed and reliability are often intuited hand-in-hand. Speed can be a good proxy for general engineering quality. If an application slows down on simple tasks, then it can mean the engineers aren’t obsessive detail sticklers. Not always, but it can mean disastrous other issues lurk. I want all my craftspeople to stickle. I don’t think Ulysses is badly made, but I am less confident in it than if it handled input and interface speed with more grace. Speed would make me trust it more.
It feels–intuitively–that software (beyond core functionality) should aim for speed. Speed as a proxy for efficiency. If a piece of software is becoming taurine-esque, unwieldy, then perhaps it shouldn’t be a single piece of software. Ultimately, to be fast is to be light. And to be light is to lessen the burden on someone or some task. This is the ultimate goal: For our pocket supercomputers to lesson burdens, not increase them. For our mega-powered laptops to enable a kind of fluency–not battle, or struggle–of creation.
All that said: It’s easy to write an essay about fast software. It’s difficult to make fast software. But when it’s made, we’re all grateful.