« Getting to know the iPhone | Main | Dial-a-burglar system »

February 14, 2009

On making stuff break

One of the reasons yours truly CW hasn’t been doing much blogging hereabouts is the amount of time that’s been chewed up doing what was supposed to be part-time systems administration and tech support for a couple of small businesses.

We’d love to know how much the average business pays for the computer illiteracy of its users.

We had a beauty the other day, for instance. The user reported that the mouse on her PC refused to work. She told us she’d unplugged it and plugged it in again, and it still didn't work.

So we sighed, hopped on the scooter, motored down there, and confirmed that yes, the mouse didn't work. Why didn't it work? Well, fortunately we didn’t exchange the mouse or start fiddling with Device Manager. Instead we popped under the desk and checked the cable. Sure enough, it had been forced into a spare modem slot. We have no idea how she managed it. When we stuck it into the right slot, it worked. Which led, of course, to several rounds of "Well, I only put it back where it came from, so why didn't it work before?", etc.

Our new policy is to ban users from plugging anything in, or pulling it out, unless they really know what they're doing.

Here’s a less innocent example of unnecessary expense and trouble.

 

It took half an hour last week to coax a new label into the Dymo LabelWriter 400 Turbo that stopped working several months ago. Now they needed to get it working again. We found that after finally convincing the machine to accept the label, when we pushed the print button it advanced the labels, but it wouldn't print.

It wasn't until we rang Dymo's [excellent] tech support line that we discovered the embarrassing cause via the following dialogue:

"Can you lift the lever on the left?"

"What lever?"

"The lever that you lift to insert the labels."

"Umm. We don't have a lever."

It was pretty obvious what had happened to that lever. It had been snapped off, and not, we're convinced, in some random act of self-destruction. We suspect the culprit was a previous employee who had a particular fear and hatred of technology. Somehow, people like that seem to have developed the knack of provoking software and hardware to misbehave.

They can be a tremendous cost on a business. It isn’t only that they seem to attract disasters, possibly under the theory of “revenge effects” advanced by Edward Tenner in Why Things Bite Back: Technology and the Revenge of Unintended Consequences.

They can also delay or frustrate the introduction of cost-saving innovations, and frequently they seem to engage in expensive duplication of effort, out of some misguided apprehension that they have to have something to fall back on if the software or hardware breaks. If necessary, it seems, they’ll break it.

We wonder if part of the interviewing process for new employees should be aimed at discovering whether the candidate has some unconscious hostility to technology, and if so, eliminating them.

Posted by cw at February 14, 2009 01:56 PM

Trackback Pings

TrackBack URL for this entry:
http://bleedingedge.com.au/cgi-bin/mt/mt-tb.cgi/1673

Comments

CW
Years ago (circa 1982) i wrote a Dbase III app (as an exercise in understanding a PC) for a surgeon friend of mine. We implemented it and I thought I would make a fortune selling and supporting it. However what killed the idea was the support. The field road test showed constant data corruption. I would spend hours restoring the data and bringing it up to date (Receptionist would always forget to change the backup tape). How to charge for all this? Cost of PC was about $4000 and I could spend 10 or more hours a week just correcting the data. There was a clear resistance to paying for this type of support.
I was sitting at the PC restoring data when the PC screen gave an "electronic jump" Receptionist commented "it always does that when we turn on the X-Ray machine"
At that point I decided not to give up my day job.

Posted by: bryan at February 14, 2009 08:15 PM

We have a problem at work with the Aftersales computer always acquiring Viruses and Trojans. Aftersales consultants always have the highest turnover, so we may have 3 or 4 different users over the course of a year. Very few of them know anything about maintaining a computer.

On the most recent resurrection, I decided to experiment with Windows Disk Protection in Windows Steadystate.

After a month with the new computer, we now find out that every little program they use needs Administrator access to run. These a programs written by major companies recently (since the release of Windows Vista). You would think these developers understand the difference between User Space and System Space. Every program needs to be specially massaged to write user data to D: drive and leave C: drive alone.

Posted by: Dan Woods at February 15, 2009 09:03 AM

Post a comment




Remember Me?



(you may use HTML tags for style)