[From Bill Powers (2009.02.26.0300 MST)]
It's amazing how long it takes my brain to see something obvious.
I've been struggling for days with a computer that has things wrong
with its operating system, and spending hours looking up remedies on
the Web and trying to figure out how to carry them out, or simply
trying to understand what they mean. And making mistakes that cure
one problem and cause another. It has finally dawned on me why this
is such a frustrating problem.
Suppose I want to build a control system that will turn on a light
when a room gets dark. If I were to design this system the way
operating systems are designed, I would get a photocell to measure
the light level in the room, and hook it up so that when room gets
dark, a relay closes and turns on a printer which prints
THE ROOM IS DARK. PHOTOCELL HAS ENCOUNTERED A PROBLEM. LIGHT SUPPLY
FAILED. CANNOT START ELECTRON FLOW INTO LIGHT BULB. ILLUMINATION
SERVICE IS CORRUPT AND UNSTABLE. SWITCH.DLL NOT FOUND.
I would package this device with a printer and sell it for lots of
money so people who bought it would understand why it doesn't turn
the light on when the room gets dark, although it was sold as a
device for accomplishing that purpose. On the back of the package
under a label, of course, in small print, there is a notice saying
that opening the package is equivalent to accepting the End User
License Agreement, which clearly states that this device is not sold
with any assurance that it does anything useful, and anyway all you
are buying is a license to try to use it.
On the other hand, if I wanted to make sure this device would,
indeed, turn the light on when the room is dark, I would use the
photocell to active a relay when the room gets dark, and hook up the
relay so it turns on the light.
There is something very peculiar about a machine that delivers error
messages to its user. It's one thing for the user to try to do
something with the machine and have it not happen or have the wrong
thing happen. That is an error that the user doesn't need to be told
about. But it's another thing for the user to be told "I know what is
wrong, but I'm not going to fix it and I'm not going to tell you how
to fix it." This isn't information, it's mockery. If you know
something is missing or broken, I ask this machine and its designer,
why don't you know where to get another one? If you know how to fix
the problem, why don't you just fix it instead of telling me all
about it? If you don't know these things, what are you doing
designing machines anyway?
Fred Nickols has been asking about practical applications of PCT. I
can see a great big one here. Let's take all those error messages and
throw them in the trash, and in their place build little programs
that fix errors when they are detected.
How does a program know that, for example, "igfxtray failed because
hccutils.dll not found"? Obviously, it tried to find that dll and
didn't. But how did it know where to look? Obviously, it knew where
that dll was supposed to be. It's like the worker who comes on the
job and sees that a tool is missing. How do you know something is
missing? You try to use it and it's not where it's supposed to be.
So what is the worker who finds the tool missing supposed to do? Give
up and go home? Write out a complaint and drop it in the suggestion
box? How about going to the place where tools are kept and getting
one and putting it in the tool rack, or calling up whoever has that
responsibility and telling them to bring the tool? Any worker who
wants to do his job finds the tool somehow and gets on with it.
Well, this worker isn't in charge of seeing to it that the tool rack
is properly equipped -- that's the job of the people in the cage on
the other side of the factory. But what's to say that the tool rack
can't have a little printed notice in the space where each tool is
supposed to be, saying "If this tool is missing or damaged, dial 3333
for a replacement." Either the tool rack has the tool in it, or you
can see the notice. Heck, there could be a microswitch on the rack
that automatically signals the toolroom after a suitable delay.
What I'm saying is, let's build these systems like control systems.
Let's give them perceptions so they can tell what is happening, and
reference signals telling them what is supposed to happen, and
comparators that can see when there is a difference between those
things and generate an error signal. And let's hook up the error
signals not to send error messages, but to bring the perception
closer to the reference state, or to alter reference signals in other
systems that will take care of doing that. If the error correction is
going to take a while, we can allow one message to be delivered to
the user: "WORKING." If that message goes on too long, it gets
replaced with "CALL THE DOCTOR."
Obviously, somebody knows what to do when hccutil.dll is not found.
The user of the program doesn't, but when the machine is taken to the
repair shop the repair person knows, or knows how to find out. If the
repair person knows, that knowledge can be put into a data base and
the error detection program can use it. The data base doesn't even
have to be in the computer (except for the parts relating to internet
communication). It can be in Bellevue, Washington.
Let's start a letter-writing campaign: NO MORE ERROR MESSAGES!. Every
time there is an error and it gets fixed, make a sketch of the
control system that could do it and mail it to Bill Gates or Steve Jobs.
And Fred, maybe you can start doing that with industrial designs.
Best,
Bill P.
No virus found in this outgoing message.
Checked by AVG - http://www.avg.com
Version: 8.0.173 / Virus Database: 270.11.3/1973 - Release Date: 2/26/2009 7:03 AM