Fast Software, the Best Software

I love fast software. That is, software speedy both in function and interface. Software with minimal to no lag between wanting to activate or manipulate something and the thing happening. Lightness.

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.

nvALT and Simplenote: The Power of Instancy

One of my most used, most speedy pieces of software is nvALT. It's an oddly named, very bland application. Just a database of plain text files with a plain text editor bolted on. But it's fast. The fastest piece of text cataloging software I've used. It opens instantly and produces results instantly.

My nvALT database is full of ten years of notes. Open it and your cursor is already in the search field. It is keyboard friendly software: If you're ever not in the search field, just hit ESC, and you'll land there. Type a few letters and all the notes with those letters appear. It is the best instantiation of an off-board brain I have. Any piece of text with value in my life gets dumped into nvALT.

nvALT syncs with Simplenote. This is handy because nvALT is macOS only. So you can use the Simplenote iOS app to keep your extra brain nearby on the go. Simplenote also has a macOS app. You may think: Why not use the Simplenote desktop application? Because – it's not quite as fast. We're talking milliseconds, but it's enough that you feel the difference. It's the difference between the $1000 Japanese garden shears and the $150 garden shears. They both cut just fine, but if you work in the garden all day, you will (probably?) feel the difference.

Ulysses and the Frustration of Slowness

I write mainly in Ulysses. Even now, I'm writing this in Ulysses. Ulysses works well for organizing large-ish bodies of writing. The organization is mostly why I use it. But it can slow down. Ulysses has slowed down on a number of occasions. If I have a 5,000 word article and type towards the top of it, it sometimes can't keep up with my typing. It re-renders the whole thing with each keystroke. This drives me bonkers.

But the organization and simplicity of the application outweigh this sometimes-slowness. Still, the slowness feels indicative of unseen rot on the inside of the machine. The slowness is like an off smell. I don't trust the application as much as I would if it didn't slow down on such a small text file. 5,000 words is nothing. Faith is tested: It makes me wonder how good the sync capabilities are. It makes me wonder if the application will lose data.

Speed as a Proxy for Engineering Quality

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.

As a counter example, Sublime Text never slows down for me. I can throw a 50,000 line file at it and it zips along. You may wonder why I don't write in Sublime Text (as I sometimes wonder). And the answer is: It's just not quite nice enough for full composition. Sublime's typography, spell check, file organization (no keywords, inability to organize order willy-nilly, etc) – just not as refined. Sublime Text is optimized for code, not words. Whereas Ulysses is word-focused. The difference is subtle but meaningful.

That said, Sublime Text has – in my experience – only gotten faster. I love software that does this: Software that unbloats over time. This should be the goal of all software. The longer it's around, the more elegant it should become. Smooth over like a river stone. I have full trust in the engineering of Sublime Text because I've used it for over a decade, but also because it always feels like a fast, focused tool (even though it's actually very complicated) and has only become faster the longer I've used it.

The Decline of Adobe Giants

Adobe Lightroom does not feel like a fast, focused tool. Nor does Photoshop. At one point, they did. It's why I chose them. Photoshop in the 90s was very fast. I don't think I'm invoking some halcyon fantasy. It was truly a sparky piece of code. Similarly, I started using Lightroom around 2007 because it was so much faster than Apple's Aperture. But Aperture is gone and Lightroom has not smoothed out over the years. Lightroom is a gangly blob, with lots of dull, slow edges. Why can't it get faster? This is a mystery for the ages, but I suspect it's because of:

1. Feature bloat.
2. Core engineering sub-optimized for so much feature bloat.

Is this why Adobe released Lightroom CC? Probably. It's sometimes easier to make a new program than to fix the old one.

Photoshop is now a turkey. Just opening the new file dialog in Photoshop takes seconds. Seconds to create a new, blank file. In 2019. If you press Cmd-Opt-Shift-W to export an image, it takes 3-5 seconds to load that screen. (And if you accidentally press Cmd-Opt-W, it closes all your windows.) Slower and slower with each release. It's why I spent money on Affinity Photo. Simply for speed. That's it. I still pay for a Creative Cloud license (for Lightroom Classic and InDesign mainly), but I happily paid for Affinity – a vote with dollars – because it's so fast, and especially fast at exporting files for web consumption. I sigh – actually sigh – whenever I have to open Photoshop.

Speed as a Tremendous Commercial Asset

One could argue that design apps like Sketch have grown in popularity because of speed. Sketch was so much faster, simpler, and more UX design focused than most anything Adobe offered when it was released. It had reliability issues, but we were willing to overlook them because it was, once again, just fun to use. In this way, speed can be a tremendous commercial asset. When it comes to software that people live in all day long, a 3% increase in fun should not be dismissed.

Figma is another design tool in the vein of Sketch or Illustrator. In spite of being browser-based, Figma is so fast that I laugh from delight whenever I use it. It feels precisely as fast as everything should be on a contemporary computer – which is, extremely. It feels loved. I know the engineering and design teams behind it and I know it is loved. It is built from a position of craft. Close-to-the-metal craft. And you feel it. Not only in speed as speed, but speed as intuitiveness. That is: The tools work more sensibly than the same tools in, say, Illustrator. The pen tool for example. In Figma the pen tool operates from a position of rationality. In this sense, "speed" manifests not only in work per computer cycle, but work per user cycle.

The Slow Death of Google Maps

Google Maps is dying a tragic, public death by a thousand cuts of slowness. Google has added animations all over Google Maps. They are nice individually, but in aggregate they are very slow. Google Maps used to be a fast, focused tool. It's now quite bovine. If you push the wrong button, it moos. Clunky, you could say. Overly complex. Unnecessarily layered. Perhaps it's trying to do too much? To back out of certain modes – directions, for example – a user may have to tap four or five different areas and endure as many slow animations.

We endure because Google Maps, otherwise, is a treasure trove of data about the world around us. It's a downright marvel of information, and a marvel of an application. More and more, however, that information is being hidden behind multi-UI variants, and a UI that seems to vary week-by-week. My outside intuition is that this is a management issue perhaps endemic to Google itself, not an engineering issue.