OddThinking

A blog for odd things and odd thoughts.

Reacting to the Unresponsive

Over the past 12 months, I have been getting more and more frustrated at how slow my machine sometimes gets. It has taken me a while to pin-point what my objection is.

Today I found the words.

As my computer gets faster and faster, I am finding that the CPU is less frequently the bottle-neck – it is far more likely to be the disk-drive or network I/O. After the last CPU upgrade on my home machine, I marvelled at how many days it was before I saw the CPU hit 100%.

Of course, occasionally I’ll do some processing work that is CPU intensive – I run a video-processing batch job each week that takes several CPU-hours to complete. However, my day-to-day work doesn’t tax the processor at all.

However, in this day and age of ubiquitous CPU power, moderately fast networks and plentiful memory, my tolerance for unresponsive software has plummeted.

I never again want to see “Not responding” in the Windows Task Manager. I never again want to see an unpainted window, waiting for a refresh. I never again want to hit a Cancel button on a progress dialog repeatedly wondering if it will ever cancel. When I elect to close an application, it should close NOW!.

I know writing real-time programs is harder than batch programs; I’ve been there. I don’t care. I am showering the developers in the luxury of sufficient resources. I don’t complain about bloatware – okay, that’s a lie, but I am not the first in the line; I am up near the back of line, with the more patient people with fast machines and less demanding applications.

In return for these luxurious resources, all that I am asking that when I select an item I get an immediate response. It don’t demand that it finish the operation quickly, but I do demand that it respond with feedback quickly – and if I am not happy with the rate of progress, I demand that it can be aborted quickly.

I am as mad as hell about having a machine using only 10% CPU and 10% RAM being too busy to refresh its windows, and I’m not going to take it any more!


Comments

  1. But surely these principles (ie responding with feedback, provision to abort) are applicable to all software, whether designed for recent hardware or not? Why should good programming practice correlate with plentiful computing resources?

  2. [Stop Press: It has now been published.]

    Alastair, you are of course right. This is just good practice. However, here’s my hypothesis about why faster hardware seems to makes this problem worse.

    I was taught that the level of patience that people have with delays with computer software is related to their expectation for delays. This has some odd impact in UI design.

    For example, sometimes you can build different algorithms into editors that are – according to a stopwatch – objectively faster. However, if they introduce delays into processing of keypresses at times that are unexpected (and thus appear random), then they can seem subjectively slower to the user.

    I suspect that unresponsive applications have always been just as prevalent (or perhaps even more prevalent) than they are now. However, I am used to a majority of applications that are responsive. These days, they can process data as fast as I can enter commands. As a result, the applications that are unresponsive appear relatively worse, compared to responsive programs, than they used to.

    Does that sound like a plausible hypothesis?

Leave a comment

You must be logged in to post a comment.

Web Mentions

  1. OddThinking » More Thoughts On Software Slowness