logo
Kurashizu Blogwhere ideas flow
  • Home
  • News
  • Blog
  • About
  • Home
  • News
  • Blog
  • About

© 2026 Kurashizu. All rights reserved.

Admin·New Post·Service Status
Powered by Cloudflare·02.11.26
← Back to news

Fast Software, the Best Software (2019)

Original article
craigmod.com|100 points|53 comments|by ustad|Jul 5, 2026

Fast Software, the Best Software (2019)

A reflection on the intersection of performance, perception, and engineering quality.

Originally penned by Craig Mod (Roden 028), this piece explores why the velocity of an interface is not just a technical metric, but a fundamental component of the user experience.


The Philosophy of Velocity

I have a deep affection for software that responds instantly. I'm talking about tools where the gap between a user's intent and the system's execution is virtually non-existent. While speed often correlates with simplicity, that isn't a hard rule.

"Speed in software is probably the most valuable, least valued asset."

To me, the difference between a snappy app and a sluggish one is the difference between a tool that blends seamlessly into your workflow and one you dread opening. It is a subtle joy—much like the generous margins in a well-designed book—that improves the experience even if you can't quite articulate why.

The "Garden Shears" Analogy

Consider the difference between two tools:

  1. Premium Japanese Garden Shears (\approx \1000$)
  2. Standard Garden Shears (\approx \150$)

Both will cut a branch. However, if you are gardening for eight hours a day, the precision and effortless glide of the expensive pair become palpable. Software is the same.


Case Studies in Performance

⚡ The High-Performers

I rely heavily on nvALT. It is essentially a plain-text editor fused to a database of text files. Its efficiency is rooted in its keyboard-centric design:

  • Instant Navigation: Press ESC →\rightarrow→ land in the search field.
  • Rapid Retrieval: Type a few characters →\rightarrow→ matching notes appear immediately.

I use the Simplenote iOS app for mobile access, but on the desktop, I stick to nvALT. Why? Because of milliseconds. That tiny delta in response time is the "Japanese shears" of the software world.

The Evolution of Sublime Text

I've used Sublime Text for over a decade. Unlike most software, it seems to unbloat over time. Because it remains a focused, lightning-fast tool despite its internal complexity, I have absolute faith in its engineering.

⚠️ The "Unseen Rot"

Then there is Ulysses. It is fantastic for organizing long-form writing, but it has a flaw: when I'm working on a 5,000-word piece, the cursor occasionally lags behind my typing.

While the app's utility outweighs this slowness, the lag creates a psychological rift. It feels like stability "unseen rot" inside the machine. If the engineers aren't obsessive about input speed, I start to question other invisible systems, such as:

  • Is the sync engine reliable?
  • Is the data architecture sound?
  • Are they detail-oriented?

The Bloat Cycle: Adobe and Beyond

The trajectory of Adobe products provides a cautionary tale. I adopted Lightroom in 2007 because it demolished Apple's Aperture (now defunct) in terms of speed. However, Lightroom has grown sluggish over the years.

SoftwareStatusPerformance TrendUser Sentiment
LightroomActive↓\downarrow↓ DecreasingFrustrated by bloat
AffinityActive↑\uparrow↑ High"A vote with dollars"
FigmaActive↑\uparrow↑ Extremely HighPure delight

In Lightroom, a simple command like Cmd-Opt-Shift-W (Export) can take 3-5 seconds to trigger the screen. Conversely, I moved to Affinity because its export speeds are vastly superior.

The "User Cycle" Metric

Sketch gained traction because it was faster and more focused than Adobe's offerings. Figma took this further. Despite living in a browser, Figma is so responsive it's almost funny.

In Figma, the pen tool feels "rational." This introduces a new way to measure speed:

Efficiency=Work PerformedUser Cycle\text{Efficiency} = \frac{\text{Work Performed}}{\text{User Cycle}}Efficiency=User CycleWork Performed​

It isn't just about CPU cycles; it's about how much friction exists between the human's thought and the digital result.


The Tragedy of Google Maps

Google Maps is currently suffering a "death by a thousand cuts." While the underlying data is a global marvel, the interface has become a labyrinth of slow animations and shifting UI variants.

This feels less like an engineering failure and more like a management failure. The friction became so great that I did the unthinkable: I reinstalled Apple Maps. While Apple's data may be inferior, the app is "zippy." I traded data depth for interface responsiveness.

The Absolute Bottom

If you want to see the nadir of software clunkiness, look no further than iTunes. It became a bloated monolith, burdened by trying to be everything to everyone, and in the process, it lost its soul to slowness.


Summary of Findings

To maintain trust and usability, software must prioritize:

  1. Input Latency: Latency≈0\text{Latency} \approx 0Latency≈0
  2. Consistency: No random stutters in large files.
  3. Focus: Avoiding the "feature bloat" trap that plagued Lightroom.
def user_experience(speed, features):
    if speed < threshold:
        return "Reluctant Usage"
    elif speed > threshold and features == "bloated":
        return "Diminishing Returns"
    else:
        return "Seamless Integration"