Simple Pleasures Are the Best

Years ago, when my dad was in his seventies, I tried to teach him how to use a computer.  He was overwhelmed by what was for him a serious challenge.  This was long-enough ago that there were still dedicated "word processors," units which looked like a computer keyboard and monitor, but which had only one function — to create documents.  Learning how to use them was far easier than learning to use a computer and all it's distracting features, even in those days when they operated in a relatively limited field of effort.

My father tried, but a word processor was not for him.

I realized that the only technology my father might appreciate, even master, would be the closest technology to the manual typewriter he'd been using his entire adult life, a machine which would mimic his old Royal's features.  I was happy to show him how to work an electric typewriter, and he took to it like a fish to water.

I believe that one should consider before racing to adopt the latest technology, particularly if you are efficient using the technology you're used to using.  You should account for the expense, time to adjust, retrain, and even the loss of some aspect of your current process that you might come to wish you had retained, for whatever reason.

I posted about whether or not to agree to software updates years ago.

Be at ease with your own expert notion of what's comfortable for you.

Always use the simplest effective technology.

If It's Fixed, Do We Care What Went Wrong?

Today my scanner would not respond, saying another program had the scanner in use, reporting this to me in an error message.  I closed every program I thought might use the scanner, no change.  The error message still maintained that the scanner was in use, and advised I reboot my computer.  It occurred to me I might just reboot the scanner, and when I did, the error went away and I was once again able to use it.

This is an example of countless times we know how to make a problem go away without actually knowing what the problem is.  I often think that most computer problems have very specific causes, like the old cartoon about the mainframe dying every night at a particular hour, confounding technicians, simply because the cleaning lady unplugs it to plug in the vacuum.

It seems likely to me that my scanner was not in use at all, but that some data bit had tripped to give the appearance that it was.  Some technicians delight in tracing such errors down, and are often paid handsomely for their efforts.  Still I wonder why application code doesn’t report errors more reliably and with greater accuracy.

In the old days, technicians poured over “stack overflow” reports which left a trail of… well, everything a computer was experiencing at the time of a system crash.  No one has time for that anymore, so we rely more heavily on error messages to tell us what went wrong.

I feel there’s a lot of room for improvement in error messaging, and it might be interesting to actually know what’s happening when things go wrong.  

Of course, our software applications and operating systems are vastly more complicated than they once were.  Perhaps there’s no time to test every conceivable interruption, and to neatly alert us what’s wrong.  But if each step in a software program verified what it was doing, in theory, when it was not able to perform that step, it could throw report an error that would state clearly what it was unable to do.  It might even suggest the cause of its problem, identify a key antecedent to it’s action, or other programs that were interfering with its operation.

Persons more interested in all this have addressed everything I just mentioned.  But I sense that error reporting — and recovery from error — could be much more robust than it is.  

Perhaps the reason error recovery isn't more robust is that it’s just easier to restart the program.