<Bill Cunningham 940602.1730>
This post consists of two parts, arbitrarily called "bad new" and
"good news."
First the bad news.
It might help by starting with an explanation of my job. Put
simply, it is to translate in both directions between the realm
of science and the realm of operational users, with
interpretation to the former on how they might serve and to the
latter how they might find application. I've become moderately
good at this, which is fortunate -- for that is why they pay me.
Over a long period of time, I have learned two rules that have
proven useful enough to apply as a guiding principle. They force
me to the heart of my work and they help weed out that which is
not cost-effective to pursue.
a. It doesn't exist if I can't understand "it". This requires
considerable effort on my part to understand "it" and some
effort, occasionally major, on the part of the purveyor of the
idea at hand. This is a layered protocol problem of no small
magnitude, almost impossible without cooperative partner(s).
b. If I can't explain "it" to my operational customers in THEIR
language, and in terms of THEIR problem, as THEY see the problem,
then "it" is irrelevant. This places the greatest burden on me
because my customers are less likely to enter into a lengthy
dialog that might assist the translation.
With respect to PCT, Rule (a) seems to have been satisfied --
within reason, anyway. However, I have just been told that my
customer's problem is not relevant to PCT unless the problem is
framed in terms of PCT, that there is no desire to serve my
customer on any other terms, and that PCT will not be relevant to
my customer until the customer reframes HIS problem correctly.
It looks like Rule (b) will prevail no matter what, and that I
should invest no more time in the subject. I'm a stubborn
sonofabitch, however, and still have hope this isn't really the
case, as you will see under the heading of "Good News", below .
My customer's problems remain. Despite my hopes for PCT, I must
resume the search for approaches RELEVANT TO MY CUSTOMER.
Did you ever wonder why so much difficulty in selling PCT as a
great idea? If the customer's problem is irrelevant to you,
don't expect much acceptance. Dag shares his introductory
letters with the net. The repeated theme is to show some
relevance TO THE CUSTOMER. Ed Ford seems to be the most
successful in demonstrating relevance TO HIS CUSTOMERS.
Anybody want to bet that customers control for relevance to THEIR
view of the world? Anybody got a boss or employer who thinks his/her
view is notrelevant?
And now the good news.
Like Martin, I am beginning to have some success explaining and
selling PCT as something useful to my customers. They seem to
think I have a good handle on their problems and this builds a
trust level that makes it easier to explain things that they
don't see as immediately useful. That's why I don't want to drop
the potential application of PCT to their information problem
that is also clearly a perception problem.
Bill P's comments about the difference between inate behavior and
learned behavior sparked what might provide a feasible solution
to my customers. If you will pardon the metaphor, the inate
system is like computer hardware with whatever firmware comes
with it. It does what it does, but isn't very useful. The
learned behavior is like application software, and that is what
makes the computer really effective. In between, we have an
operating system that must deal with the hardware rule set and
provide a more flexible environment for the application software.
You can't develop an operating system without the hardware rule
set and you can't develop application software without
understanding both the application problem and the rule set(s)
with which it must deal. The customer, however, really doesn't
care what part of the overall system solves his problem.
And so, it becomes very important to understand the boundary
between the "inate rule set" and the "learned rule set." Before
anybody misunderstands that comment, I am using the term "rule
set" metaphorically and NOT as in actual computer design. So
Rick's great insight about the program level is a tremendous leap
forward. It is a much clearer exposition of what I was
struggling show by analog gates selecting "courses of action."
Bill P's extension to the sequence level is neat! By extension
of the idea, can learned behavior be considered as providing
reference to the program level? Do we have a new level, clearly
marked "learned behavior" If not, where and how is learned
behavior imposed on the inate system? This is a no-shit general
purpose question with tremendous opportunity for application.
Best to all and malice to none,
Bill C.
PROFS: mon1(cunningb) Internet: cunningb@monroe-emh1.army.mil
Phone (804) 727-3472/DSN 680-3472. FAX ext 3694/2562
*Eschew Obfuscation*