The Need For Speed: a partial dissent

Craig Modi wrote an excellent essay on “Fast Software: The Best Software,” which has been widely praised in the software world. As usual, Michael Tsai has an excellent overview of the commentary.

You’d think this was all self-evident. “I love this essay so much,” writes Jon Gruber, “I wish I could kiss it.” Why shouldn’t software be faster?

First: some speed changes are illusions. Lots of things we do on today’s computers seem slower than the corresponding operations we did ten or twenty years ago, but often that’s because “the same thing” is thousands of times harder. We assume elegant typography everywhere; that takes lots of work where we used to think the VT-100’s monospaced fonts were elegant.. We want to open a document: where a folder back then might have a dozen documents on a disk with thousands, now the folder has a thousand documents and document-versions on a disk with millions.

Second: how much speed do you want to pay for? I was driving home the other day, and noticed that the car ahead of me was a Lamborghini. That driver had 691 horsepower, my Honda Fit has 130, and it took us precisely the same amount of time to get from Watertown to Arlington.

Let’s look at the back of the proverbial envelope and estimate the numbers on an actual success story. I’ve spent the last few days in the (brand-new) profiler, looking at ways to speed up Tinderbox. This went unusually well: I reduced the load time for a big document — the Tinderbox planning notes — from almost eight seconds to just over 3.

At 3,700 notes, 700 links, and a quarter of a million words, this is not an atypical Tinderbox document, but lots of people don’t need documents this big. Significantly, no new Tinderbox user and no sales prospect is likely to encounter a document this big: it takes times to make that many notes. We can’t expect the speed bump to have much impact on sales. So, the cost of the speed improvement has to be born either by Eastgate or, through upgrades, by the Tinderbox community.

It’s hard to know exactly how many beneficiaries there are. On any given day, there are a few thousand Tinderbox users. (There are lots more Tinderbox owners, but some of them are on vacation, and some of them only use Tinderbox in the winter, and some of them are between projects or switched jobs or have decided to raise lambs instead.) Let’s say a thousand users/day have documents this big, that they save 5 seconds per load, one load per day, and that their marginal cost is $50/hr. I’ve saved the community about $70/day, or a little less than $25,000/yr. That’s a nice return on a long weekend.

But the news is not quite that good. At the same $50/hr, we spent about $2,000 on my groceries, and about $2,000 on the cost of the office, equipment, support, taxes, and such. In my experience, between 30-50% of improvements like this one turn out to be illusions: they work for simple cases but overlook some edge case that either requires lots more engineering or that vitiates the whole thing. We need to amortize the failures, so we probably should halve the community’s profit. I’d also like to budget perhaps $1000 for future maintenance and support. So, we’ve got $12,500 of savings and about $5,000 in costs.

This is good news (and better than I’d expected) but it’s not overwhelmingly good. We’re not considering the costs of selling and distributing upgrades, which will eat up a big chunk of that mildly-attractive gross margin.

Some of the time, you’re just better off waiting a few seconds for the result. Better to have a slow tool and the right answer than a fast one that makes mistakes or that gives you the answer to someone else’s problem.

Among artisanal software developers, we’re something of an outlier — through upgrades, we do have a way to share at least part of those community savings. That’s by no means a given: see this excellent presentation on the state of Twine for a counter-example.