on discovering goals

[Hans Blom, 970408]

(Bill Powers (970401.1557 MST))

Hans' model requires that the peak output needed to produce these
"one-step" corrections be inversely proportional to the sampling
interval, leading to extremely large values of output as Dt
approaches zero. Han's comment on this "feature" of his model was
that nobody told him that infinite output was to be avoided:
"you wanted perfect control, I gave you perfect control." In some
circles, this is known as "malicious compliance."

This makes a beautiful example in my class on Expert Systems, in the
part about knowledge acquisition. Thanks.

"Class, this is what we often experience in our practice. A client
comes to us for a system design and tells us what he wants. Or
rather, thinks he wants. By now you all know that every client has a
lot of unmentioned extra conditions that he takes for granted but
does not utter even once. Those requirements are unconscious, are not
"hard" and are sometimes very difficult to unearth. Somehow clients
expect us to be mind-readers. And that is, indeed, what this class is
about: to learn a method -- we call it "rapid prototyping" -- to
investigate what somebody wants, even though that somebody may not
know what he wants himself, let alone be able to express it.

When you try to get additional information, it may be provided.
Partially. Or not at all. Sometimes with irritation: "Yes, of course.
That too. You should know that". Sometimes with surprise: "Why didn't
I mention that before? It is actually my most important requirement!"
Remember this: it is normal that people do not know what they want.
They want it, sure. They just don't know they want it. Until you ask
them. Then they may become conscious of an additional requirement.
The best method is, however, to confront them with a prototype that
fulfills all the wishes that they have uttered. That prototype is
sure to be rejected. And the important lesson is: _the reason for the
rejection is the additional knowledge that you wanted in the first
place_. But it may be a painful process, both for you, the knowledge
engineer, and for the customer. For you, because you did exactly as
the customer specified, yet he rejects your design. For the customer,
because your design confronts him with his own inadequacies. Many
customers don't take that easy. Remember that, and explain to your
client that this is _normal_ and to be expected. If you don't, you
might damage his ego and our knowledge engineering firm will have
lost a customer.

"Position control" is what he wants, says the customer. Fine. Of
course, in his application. But somehow you doubt that that will be
all. "How accurate?", you ask. Well, the motor the client has in mind
is very fast, he says. It can generate a new torque stably after 20
microseconds. You've never heard of such a fast motor and think it is
tremendous overkill. The movement is slow, after all: a rotation of
one radian is allowed to take a couple of seconds. And the motor is
expensive to boot. But the client wants it. So we incorporate the
thing in our design. And we use its properties: the system generates
rapidly fluctuating torques. Great design. Extremely accurate. Almost
perfect even. You know that this cannot be all, but you've done
exactly what the client wants.

Yet the client complains. Again, that is normal and to be expected.
He complains that the motor or the whole assembly will not survive
the rapidly fluctuating torque. You doubt it, but the client
emphasizes that he does not want his extremely fast motor to be used
for what is can do, and for what it obviously was meant to do.
Strange, but you comply. The client is the client, after all. And the
first prototype has achieved its task: it brought to light that the
client has not told you all of his requirements. Theory told us so,
but now we have experienced this in practice as well. Moreover, you
have to spare the client's feelings. He seems a bit embarrassed that
he hasn't explicitly specified that he doesn't want small high
frequency vibrations, even though they don't seem to hurt the design
in any way. But the client being a client, his ideas are _good_
ideas. He is the expert, after all. Only he knows what he wants.
That's what only _he_ is expert in. The only problem is that it is
difficult to find out _what_ it is exactly that he wants. But that's
what this class is all about: finding out what the client wants, even
though the client isn't consciously aware of what that is. Or maybe
he is, but cannot express it into words. Well, time to start your
next prototype. It, too, will probably not do what the client does,
but it will at least incorporate one additional requirement. If you
have understood the client, that is. It's not _always_ the client's
fault. In fact, we take the professional attitude that it's _never_
the client's fault. That's why we often sound like psychotherapists.
That's a joke, class...

However, you somehow start to doubt the client's whole concept: the
parts somehow don't fit together very well. But the client places the
order, so you comply. Yet with this particular client you see a long
sequence of prototypes before you. Attempt to see that in a positive
light. This client is a perfectionist, and perfectionists are the
prime source of income for our corporation.

So you get rid of the high frequency vibration and incorporate smooth
operation into the system. Let's wait and see whether the client is
satisfied now. What will he judge? The performance of the system?
Most clients do, but not perfectionists. They want to look _inside_
the system as well and see _how_ you've done it. Some even go so far
as to reject solutions that are achieved in ways that they do not
comprehend. Those are our most difficult customers. And the ones that
generate most of our firm's income. So they're very welcome. And even
though the final design won't be state of the art, they will be
exactly what the customer wants. And customer satisfaction is, after
all, what we're all about.

But you keep wondering what the client will come up with next. One
thing that he's mentioned already is the high power pulses that the
controller supplies to the motor. It may help little to insist that
the power-time product will be the same, regardless whether the power
is delivered in 1 or in 10 msec. The client may have additional
concerns. Maybe he's afraid that too high currents will generate
electromagnetic forces in the motor's stator or rotor that may
physically damage the windings. That would be a real concern. You'll
have to explain that performance may deteriorate slightly if you
limit the instantaneous power, but the client doesn't seem that much
interested in optimal performance, i.e. in an exact matching of the
design with his explicit requirements. That invariably means that the
client has many more unspoken wishes. So be prepared for a lengthy
and difficult design process. There's a lot more that needs to be
discovered before this client will be satisfied.

The most difficult clients are those who, when you're finished and
demonstrate a design that leaves nothing more to be desired, say that
the design is "nothing but" what they could have done themselves in a
short time as well. In fact, their requirements were not about the
_performance_ of the system but on _you_ doing what _they_ want. So
you may find yourself, indeed, having redesigned the exact same
system that the client already had on his shelf. But don't think that
your effort is in vain in such cases. It will have boosted the
client's self-confidence; you, an independent expert, arrived at the
exact same solution as the client had in the first place, so his must
be a _good_ design. It will also and proportionally have boosted our
firm's income. That's _good_, not _bad_. Keep that in mind. If you
don't because of all the frustrations, our firm will have lost a
valuable customer.

And what _you_, the knowledge engineer, have gained is a valuable
lesson about human nature: people want what they want, not what is
best for them. If you can't accept that elementary fact of life, you
ought to consider quitting this class."

Greetings,

Hans

[From Bill Powers (970412.0745 MST)]

Hans Blom, 970408 --

Han's comment on this "feature" of his model was
that nobody told him that infinite output was to be avoided:
"you wanted perfect control, I gave you perfect control." In some
circles, this is known as "malicious compliance."

This makes a beautiful example in my class on Expert Systems, in the
part about knowledge acquisition. Thanks.

I am not as surprised as I might have been at your reply concerning what you
teach engineering students. It had occurred to me -- although I chastized
myself for being overly suspicious -- that you have, how shall I say it, a
degree of non-academic interest in promoting MCT, since you hinted that you
work for a firm that designs control systems. You have made it unnecessary
for me to bring up the subject, by admitting that your primary interest in
dealing with clients is to milk as much money from them as possible by
"innocently" giving them what they asked for instead of working out with
them what they need. That is, indeed, malicious compliance! As you say, it's
profitable as well, and I can see how MCT could help in that regard.

I have been in both positions -- that of consulting engineer and that of a
client. As a client, I have met engineers like the ones you are training:
engineers whose main concern is to avoid taking responsibility for the
product, and to show that the fault for a failed system lies with the
client's specifications. And as a consultant, I have felt the temptation to
behave in exactly the same way with a client who doesn't seem able to, or to
want to, understand that the specifications contain hidden problems, or omit
essential information. Give them what they're asking for, and show them how
stupid the design is! And make them pay for this process of "rapid
prototyping" just to make sure they get the point and learn the proper
degree of humility (not a requirement, evidently, for engineers).

Fortunately, I have never been in a position where I had to succumb to this
temptation. I have always done my best to understand the client's problem
and to work with the client to eliminate traps and mistakes before
committing to hardware or software. As a result, every project I have
carried out has been successful, meeting the mutually-worked-out
specifications and coming in on time (or early) and within (or below) the
estimated cost. In the few cases where my recommendations could not be
accepted, I simply didn't take on the job. Of course I didn't end up as a
rich retired engineer, but my work was respected. I wonder how many of your
students, at the end of their careers, are going to be able to say that, if
they follow your cynical advice.

ยทยทยท

------------------------------------------
Your practice of automatically offloading the blame onto the client shows up
in the way you weave the theodolite example into your imaginary lecture.

"Position control" is what he wants, says the customer. Fine. Of
course, in his application. But somehow you doubt that that will be
all. "How accurate?", you ask. Well, the motor the client has in mind
is very fast, he says. It can generate a new torque stably after 20
microseconds. You've never heard of such a fast motor and think it is
tremendous overkill. The movement is slow, after all: a rotation of
one radian is allowed to take a couple of seconds. And the motor is
expensive to boot. But the client wants it. So we incorporate the
thing in our design. And we use its properties: the system generates
rapidly fluctuating torques. Great design. Extremely accurate. Almost
perfect even. You know that this cannot be all, but you've done
exactly what the client wants.

Notice how you switch responsibility for choosing this motor to the client
(whose initials are WTP), when it is your own design that requires it. It is
YOUR concept of "almost perfect control" that leads to the ridiculous need
to accelerate and decelerate the moving mass 10 or 100 or 1000 times per
second. Yes, there are motors that could do this, perhaps 10 or 100 times
per second, but who was it whose concept of control required that this be
done? Not the client!

Yet the client complains. Again, that is normal and to be expected.
He complains that the motor or the whole assembly will not survive
the rapidly fluctuating torque. You doubt it, but the client
emphasizes that he does not want his extremely fast motor to be used
for what is can do, and for what it obviously was meant to do.

This seems to be a case in which the client knows more about the application
than the consulting engineer does. Of course if the engineer has to maintain
a position of superiority in the relationship, it would be impossible for
the engineer to admit this and learn something from the client.

If I had told one of your students that I needed a position control for the
theodolite, and the student came up with the design you presented, I would
fire him or her (not to be sexist about this) immediately. I would look for
an engineer who had some understanding of optical devices, and who could
imagine spending a hour or two looking through the eyepiece while something
hammered on the theodolite with alternating torques of plus and minus 20
newton-meters 10 times per second. I would hire someone who could look at
the predicted behavior and realize that the angular velocity of this device
would alternate between 2 and 0 radians per second, ten times per second --
someone who had at least some conception of how lenses and prisms are
mounted, and some feel for the forces involved, and some experience with
looking through a telescope. I wouldn't expect to have to supply such
knowledge to a real engineer, especially one who styles himself as an
"expert" or even -- God forbid -- a "knowledge engineer."

Strange, but you comply. The client is the client, after all. And the
first prototype has achieved its task: it brought to light that the
client has not told you all of his requirements.

And the engineer has exposed his ignorance of simple mechanical systems, for
the client to take into consideration. However, as you point out, this
prototype has achieved the most important objective: to siphon off a little
more of the client's money, and postpone the day of delivery yet another
month while the costs climb pleasantly above the estimates.

Theory told us so,
but now we have experienced this in practice as well. Moreover, you
have to spare the client's feelings. He seems a bit embarrassed that
he hasn't explicitly specified that he doesn't want small high
frequency vibrations, even though they don't seem to hurt the design
in any way.

That's part of the technique of shifting the blame, isn't it? The engineer
looks at a major and obvious defect in the system he or she has produced,
and minimizes it as a small high-frequency vibration that doesn't hurt the
design in any way. But -- sigh -- the client has to get what the client
wants, so with a look of patience, condescension, and long-suffering on his
or her face, the engineer goes back to the drawing board to fix the problem
that should never have occurred in the first place. And the client pays for
the goof.

But the client being a client, his ideas are _good_
ideas. He is the expert, after all. Only he knows what he wants.
That's what only _he_ is expert in. The only problem is that it is
difficult to find out _what_ it is exactly that he wants.

Once the engineer starts seeing things this way, it's perfectly clear that
nothing is ever going to be the engineer's fault. The engineer starts simply
follows orders, ceasing to think about the problem and focusing on doing
just what the client says. As a client, I can't think of a more useless
attitude to find in someone who is supposedly a practical problem-solver.

So you get rid of the high frequency vibration and incorporate smooth
operation into the system.

As you should have done in the first place (although, with your claim to
expertise being based on an advanced theory of control, you couldn't afford
to use the obvious solution: a simple servo. After all, how much could you
bill the client for a simple servo?).

Let's wait and see whether the client is
satisfied now. What will he judge? The performance of the system?
Most clients do, but not perfectionists. They want to look _inside_
the system as well and see _how_ you've done it. Some even go so far
as to reject solutions that are achieved in ways that they do not
comprehend. Those are our most difficult customers. And the ones that
generate most of our firm's income. So they're very welcome. And even
though the final design won't be state of the art, they will be
exactly what the customer wants. And customer satisfaction is, after
all, what we're all about.

That's where malicious compliance pays off, isn't it? The plumber comes in
and moves the sink to the location YOU indicated, and when the job is all
finished, says "Oh, by the way, YOU have put that pipe next to an
uninsulated wall, and it will freeze in the winter." At $50 per hour, he is
perfectly willing to rip out the sink and pipes and put them anywhere else
YOU suggest, including leaving out the state-of-the-art technique of
insulating the hot-water pipes if you happen to fail to mention it. You'll
soon have him back -- at an additional profit to him -- to add it. And
you'll find yourself apologizing for being a perfectionist.

But you keep wondering what the client will come up with next. One
thing that he's mentioned already is the high power pulses that the
controller supplies to the motor. It may help little to insist that
the power-time product will be the same, regardless whether the power
is delivered in 1 or in 10 msec. The client may have additional
concerns. Maybe he's afraid that too high currents will generate
electromagnetic forces in the motor's stator or rotor that may
physically damage the windings. That would be a real concern. You'll
have to explain that performance may deteriorate slightly if you
limit the instantaneous power, but the client doesn't seem that much
interested in optimal performance, i.e. in an exact matching of the
design with his explicit requirements.

Isn't it amazing how the engineer's own conception of perfect control, which
is what requires a motor that can start and stop at extremely high speeds,
leads to incidental problems like having to supply large currents through
inductances, which in some magical way become the client's fault? And isn't
it wonderful how the way a design tht calls for an impossible level of input
voltage and current gets translated into the client's unreasonable
insistence on limiting the instantaneous power to a physically-achievable
level? It's clearly the client's prejudice against "optimal performance"
that is causing all these problems. The engineer, whose initial design
caused all these problems, looks sternly off into space and waits for the
client to say he's sorry for causing so much trouble.

The most difficult clients are those who, when you're finished and
demonstrate a design that leaves nothing more to be desired, say that
the design is "nothing but" what they could have done themselves in a
short time as well.

I'm beginning to have a great deal of empathy with this client; he may well
have a good point there. Imagine the client's surprise when, to position
this theodolite, the engineer wheels in a computer, opens a box containing a
400 horsepower electric motor, and runs a cable to a 20-kilowatt power
supply. And when the engineer turns the system on, the lights dim and the
theodolite blurs because its tube is oscillating too fast for the eye to
follow. It snaps from one position to another, the objective lens falling
out and the prisms clinking around inside the tube, while the tripod begins
to slide across the floor under the vibrations. The motor heats up, melting
the plastic shroud around the base of the theodolite, and a little column of
smoke begins to rise from the ventilation holes. The client, showing
superhuman patience, remarks that this is not quite what he had in mind,
even though the engineer assures him that this system controls as close to
perfectly as theoretically possible.

Six months later, the optical decoder wheels have been yanked out and
replaced by a potentiometer, the 400-horsepower motor has been junked in
favor of a Barber-Coleman DC servo motor weighing one pound and drawing a
peak power of 70 watts, and the computer has been replaced by a circult
board holding a dual op-amp, a few resistors and capacitors, and a pair of
power transistors on a heat sink (which, owing to an oversight on the
engineer's part, the customer didn't have to specify). When you turn the
knob, the theodolite turns smoothly to the desired position and stops. The
client looks through the eyepiece and sees a stationary clear image.

And then the engineer presents the bill to the client, who quite
understandably goes into a rage over having to pay $500,000 for something he
could have bought off the shelf or designed himself. Yes, I think my
sympathies are very much with the client.

And what _you_, the knowledge engineer, have gained is a valuable
lesson about human nature: people want what they want, not what is
best for them. If you can't accept that elementary fact of life, you
ought to consider quitting this class."

I think I would find that choice quite easy to make. In your descriptions of
all the follies and failures of clients, you may have revealed more about
your own approach than you intended.

Best,

Bill P.

[Hans Blom, 970414b]

(Bill Powers (970412.0745 MST))

This makes a beautiful example in my class on Expert Systems, in
the part about knowledge acquisition. Thanks.

I am not as surprised as I might have been at your reply concerning
what you teach engineering students. It had occurred to me --
although I chastized myself for being overly suspicious -- that you
have, how shall I say it, a degree of non-academic interest in
promoting MCT, since you hinted that you work for a firm that
designs control systems. You have made it unnecessary for me to
bring up the subject, by admitting that your primary interest in
dealing with clients is to milk as much money from them as possible
by "innocently" giving them what they asked for instead of working
out with them what they need. That is, indeed, malicious compliance!
As you say, it's profitable as well, and I can see how MCT could
help in that regard.

Bill, I have a confession to make. I should have ended my post with a
:-). It was a joke. I am not and have never been a paid consultant. I
was kind of free-associating.... I have, moreover, no vested interest
in MCT, except where it is a useful tool, occasionally.

So you get rid of the high frequency vibration and incorporate
smooth operation into the system.

As you should have done in the first place ...

How did you like my "new MCT controller" post and program?

Greetings,

Hans

[From Bill Powers (960414.1409 MST)\

Hans Blom, 970414b--

Bill, I have a confession to make. I should have ended my post with a
:-). It was a joke. I am not and have never been a paid consultant. I
was kind of free-associating.... I have, moreover, no vested interest
in MCT, except where it is a useful tool, occasionally.

Sure fooled me!

So you get rid of the high frequency vibration and incorporate
smooth operation into the system.

As you should have done in the first place ...

How did you like my "new MCT controller" post and program?

I'm not sure I have the one to which you're referring. Is this the one you
sent just before you left? (Not the ultra-simple one, the one just before
that). The one I seem to have gives the following data:

        time ref position velocity dist u
       1.980 0.000000 0.000000 0.000000 0.000000 0.000000
       1.990 0.000000 0.000000 0.000000 0.000000 0.000000
       2.000 0.000000 0.000000 0.000000 0.000000 0.000001
       2.010 0.010000 0.010000 2.000000 0.000000 199.999999
       2.020 0.020000 0.020000 0.000000 0.000000 -199.999999
       2.030 0.030000 0.030000 2.000000 0.000000 199.999999
       2.040 0.040000 0.040000 0.000000 0.000000 -199.999999
       2.050 0.050000 0.050000 2.000000 0.000000 199.999999
       2.060 0.060000 0.060000 0.000000 0.000000 -199.999999
       2.070 0.070000 0.070000 2.000000 0.000000 199.999999
       2.080 0.080000 0.080000 0.000000 0.000000 -199.999999
       2.090 0.090000 0.090000 2.000000 0.000000 199.999999
       2.100 0.100000 0.100000 0.000000 0.000000 -199.999999
       2.110 0.110000 0.110000 2.000000 0.000000 199.999999
       2.120 0.120000 0.120000 0.000000 0.000000 -199.999999
...............
       4.000 2.000000 2.000000 0.000000 0.000000 -199.999999
       4.010 2.010000 2.010000 2.000000 0.000000 199.999999
       4.020 2.020000 2.020500 0.100000 10.000000 -199.999999
       4.030 2.030000 2.030000 1.800000 10.000000 159.999999
       4.040 2.040000 2.040000 0.200000 10.000000 -169.999999
       4.050 2.050000 2.050000 1.800000 10.000000 149.999999
       4.060 2.060000 2.060000 0.200000 10.000000 -169.999999
       4.070 2.070000 2.070000 1.800000 10.000000 149.999999
       4.080 2.080000 2.080000 0.200000 10.000000 -169.999999
       4.090 2.090000 2.090000 1.800000 10.000000 149.999999
       4.100 2.100000 2.100000 0.200000 10.000000 -169.999999
       4.110 2.110000 2.110000 1.800000 10.000000 149.999999
       4.120 2.120000 2.120000 0.200000 10.000000 -169.999999
.................
       4.980 2.980000 2.980000 0.200000 10.000000 -169.999999
       4.990 2.990000 2.990000 1.800000 10.000000 149.999999
       5.000 3.000000 3.000000 0.200000 10.000000 -169.999999
       5.010 3.010000 3.010000 1.800000 10.000000 149.999999
       5.020 3.020000 3.019500 0.100000 -0.000000 -169.999999
       5.030 3.030000 3.030000 2.000000 -0.000000 189.999999
       5.040 3.040000 3.040000 0.000000 -0.000000 -199.999999
       5.050 3.050000 3.050000 2.000000 -0.000000 199.999999
       5.060 3.060000 3.060000 0.000000 -0.000000 -199.999999
       5.070 3.070000 3.070000 2.000000 -0.000000 199.999999
..................
       5.960 3.960000 3.960000 0.000000 -0.000000 -199.999999
       5.970 3.970000 3.970000 2.000000 -0.000000 199.999999
       5.980 3.980000 3.980000 0.000000 -0.000000 -199.999999
       5.990 3.990000 3.990000 2.000000 -0.000000 199.999999
       6.000 4.000000 4.000000 -0.000000 -0.000000 -200.000001
       6.010 4.000000 4.000000 0.000000 -0.000000 0.000003
       6.020 4.000000 4.000000 -0.000000 -0.000000 -0.000003
       6.030 4.000000 4.000000 0.000000 -0.000000 0.000003
       6.040 4.000000 4.000000 -0.000000 -0.000000 -0.000003
       6.050 4.000000 4.000000 0.000000 -0.000000 0.000003
       6.060 4.000000 4.000000 -0.000000 -0.000000 -0.000003

If that's not the one, I may have lost the program to which you refer. Could
you send it again?

Best,

Bill P.