Ask HN: Something to be said for slow software?
Does quick software always leave the best impression on users? In many cases, yes of course: people hate when a slow computer gets in the way of what they want to do. But I wonder if an application that's too zippy can be perceived as cheap in some cases.
Analogy: Everybody loves low prices, but if you sell your product at a bargain (or give it away for free), its perceived value can suffer. People see a competitor who's charging more than you and assume their product is higher quality.
Compare:
* "It's free so I guess it's not worth much."
* "It takes no time to load so I guess it's not doing much."
7 comments
[ 3.7 ms ] story [ 29.5 ms ] threadUsers are sensitive to tiny differences in speed, much tinier than most software developers consider significant. For example, there have been many studies showing dramatic drop-offs in web usage with what seem like micro-differences in response times.
A good example is how Chrome is gaining rapidly in market share primarily by being more responsive. There was a fascinating post recently on a political blog I read where the author was talking about switching to Chrome even though he couldn't quite figure out why. I read it as an example of the psychological spill-over effect of performance. (Edit: here it is: http://www.talkingpointsmemo.com/archives/2009/12/the_case_f.... Well worth reading for anyone interested in the psychology of software.)
It's a fascinating conundrum that while hardware has gotten orders of magnitude faster, software has remained sluggish. I know it's fashionable to explain this by saying "but software is doing orders of magnitude more than it used to", but I think this is only a partial explanation; it's also the case that we're leaving huge amounts on the table because of the way we write code. I used to believe in the dream of an ideal high-level language abstracted away from the hardware altogether. That now seems to me a harmful delusion. What we need is a better way to combine high-level constructs with low-level ones. This in turn (veering wildly off on a tangent here...) explains the persistent appeal of C++ despite its manifest perversity. No other mainstream language is even in that game.
No doubt the case is strong case for better performance improving overall perception of the software by the user. My question though is, is there really nothing to be said for slowness anywhere? Nothing for the occasional well-placed delay? Nothing for dramatic pause? Were all those accumulated hours of my childhood waiting at loading screens on the PlayStation 1 really for nought?
Take the filters in photo editing software for example. In Photoshop, you can apply many types of filters. Let's say you apply a noise-reduction filter in Photoshop and it takes 3 seconds to run, then you switch to the Gimp and apply a noise-reduction filter and it runs instantaneously. [1] The slowness may lead users to believe that Photoshop's algorithm is more advanced. Of course, this may partially be due to branding. Photoshop is the $1000 professional photo-editing software, whereas the Gimp is free editing software put together by hackers. This ties it to your analogy in the original post. Now if the situation were reversed, and Photoshop's algorithm ran faster than the Gimp's, I suspect it would be less likely for people to believe that the Gimp's algorithm is more advanced.
This may work for a noise-reduction algorithm, because there is no one correct answer. People may believe that the microscopic differences in the pixels represent a difference in quality. Obviously, if you compare two algorithms that are supposed to compute an answer for which there is an oracle (e.g., Fibonacci or factorial), then slowness is just slowness. If I write a slow implementation of fib(n) and you write a fast one, people will know yours is better because it's faster and there's no ambiguity in the answer that could allow room for people to believe that mine is "more advanced."
Of course, this is just me speculating. I don't know of anyone that's conducted research on this.
[1] This is hypothetical. I know nothing about the performance differences between Photoshop and the Gimp.
Abstraction to the point of losing all access to lower-level details is restrictive, but having processes that handle them for you automatically is very useful. Isn't it great that compilers do a good enough job most of the time that we don't have to write binaries for each architecture by hand?
Of course, there are some legitimate reasons people might come away with the impression that a system like that is smarter, mainly that they have more idea what it's actually doing, because it was slowed down and visualized in a way that let them see it operate (instead of just spitting out the solution).
The somewhat less legitimate reason is that there are a certain group of people really enamored with high-end computing, and so if your thing runs in 2 seconds on a desktop, they assume it must suck, because why weren't you doing something fancier that needed 30 minutes on a huge cluster?
As for slowing things down for no reason, no. I don't think anyone enjoys having their time and attention put on hold.