|
A few years ago, we published a reader survey in JSS. In response, one reader simply wrote, "It ain't broke. Don't fix it." To us, that was the ultimate compliment! What better praise could the journal receive than, "We're happy with it as it is please don't change it"? And we didn't.
Of course, most of us know that this is not the general rule for the industrial sector. The items we buy are constantly being changed, and not always for the better. We're all familiar with the problems this process can cause security updates to fix earlier security updates, recalls of products released without adequate safety testing, endless hours on hold for technical support and, of course, the chagrin of finding that a product we've come to rely on has been changed into one that we don't like at all. When things aren't broken, why must they be fixed (and fixed and re-fixed)?
Much of the reason, of course, is economic. If the manufacturers of cars, televisions and various consumer items waited for their products to cease functioning before people replaced them, those companies would go out of business. However, the ongoing intrusion of change for its own (or only for the manufacturer's) sake is a cycle that needs to be stopped. Some changes are harmful, and others are simple repackaging, and therefore downright deceptive. Do you remember when television sets were (briefly) called "TV monitors," and the broken copy machine was called "down" (a rather ludicrous image)? I was in an electronics store when a customer came in to replace his two-year-old television set because it didn't have "monitor capability." I straightened him out, much to the salesperson's consternation, but I'm sure that many such sales were made that day. As for the copy machine, it was indeed broken, not "down," and needed to be fixed, not rebooted and "brought back up." Customers frequently had to insist on it, though.
I've written many times in this column that consumer voices have power. That means being a little less lazy about telling manufacturers when we like something and want it left alone, as well as when we don't.
As system safety professionals, it also means conveying that same message to our vendors, peers and employers, no matter how large and seemingly powerful those entities may be. We've made quite a bit of progress. Our .doc, .pdf and other file types will now open in older versions of their respective software, even if we have to put up with annoying "you won't get all the features!" windows. Automobile seatbelts have not been removed in favor of airbag systems that fail to consider the average woman and child. Cellular phone numbers remain private by default, rather than incorporated into public- and marketing-access directories.
Yet the need for qualified review remains critical, and that isn't likely to change. Remember the history of Therac-25, in which an "upgrade" of a formerly harmless machine resulted in radiation overdose and the tragic and painful deaths of two cancer patients? As the commentary by Leveson and Turner1 makes clear, accidents are complex events, and technological "changes" need to be thoroughly investigated by persons with the credentials, experience and expertise to do so adequately. If consumer voices have power, how much more power is rendered by Mr./Ms./Dr. Consumer, PE, CSP? Let's add our voices, especially where they count the most.
As system safety professionals, that is our mantra, and it's a good one. Please, don't fix it.
 |
Update: Do You Want Meatballs with That?
In the March-April 2006 (print) edition of the journal, I promised an honest answer about whether I got around to sorting out the maze-like tangle of cables in my office. I'm pleased to report that I did, and that I heard from a few readers who tackled and resolved similar office technology problems. My thanks to all those whose encouragement helped their fellow safety professionals gain release from self-imposed technology corners!
|
|
Ann Waterman
Copyright © 2006 by A.S. Waterman. All rights reserved.
1Leveson, Nancy and Clark S. Turner. "An Investigation of the Therac-25 Accidents." In IEEE Computer, Vol. 26, No. 7, July 1993, pp. 18-41.
|
