Conference heron::euro_swas_ai

38.0. "ABOUT WHAT MAKES A KE A KE ..." by MUNEDU::BUERKERT (HEINZ 57-Varieties) Mon Nov 21 1988 10:07

    

             <<< CREDIT::$222$DUA16:[NOTES$LIBRARY]EXPERT.NOTE;1 >>>
================================================================================
Note 127.7                 Apprentice vs Journeyman KE                    7 of 8
ISTG::KELLY "grasshopper"                           212 lines   7-NOV-1988 12:55
                                    -< KEs >-
--------------------------------------------------------------------------------

Greetings,


   Let me offer a clarification. The program Andy mentioned seems to be the
"AI Fellowship Program" which is a joint arrangement between Ed. Services and
ISTG to train customer KEs. The training is, indeed, free to the customer,
but, by my calculations, has yielded to-date several $million in DEC sales 
as a result; and, so, has been judged hugely successful. The program consists 
of 8 weeks formal training (Ed Serv), 1 week re-training (ISTG: because the 
training course doesn't cover everything of use to a KE), then 15 weeks 
apprenticeship (ISTG: work on a project the customer comes in with, which must 
be approved by a DEC KE before the customer enters the program).

   So far, we have put through 29 customers (in one year), from the US and 6
foreign countries. (All Fellows live here for the 6 months). Projects have
included every imaginable domain and paradigm from corrugated box manufacture 
to hypothecated real estate valuation to database design (see Andy Bennett for 
that one) to telecomm network routing to computer network security to 
hydrocarbon exploration to automobile muffler design/configuration. In fact, 
the AI Fellowship program does more AI work with more DEC customers than any 
group in DEC. (I maintain a list of projects if anyone's interested).


----------------

    To answer Paul's original question about experiences as an apprentice and
working with apprentices:

           Way back, when I first came to DEC with 3 years experienced as a KE, 
I was put into the AI Training course to learn DEC's way of KEing. I found the
course was modelled after the Maoist Political Re-Education Camps in communist 
China. And I thought that doing a checkers-playing program (required for 
graduation) was a silly waste of time (and decided to do a money market 
advisory system for a prospective customer (a Tokyo Bank) instead). As a result,
I was booted from the course for recalcitrance; the money market expert system 
became a standard demo shown to DEC's international brokerage, banking, and 
insurance accounts as an example of what DEC could do in financial AI; and, 
in all the years since, I've never heard of a customer asking for a 
checkers-playing expert system. 
    I still have the same problem with the AI Training course at DEC that I did
then: it is designed for the convenience of the teachers (who are not KEs, and
seem to feel threatened by real problems, not games), not for the benefit of 
the students.

           Now that I'm on the other end of the arrangement (I get the new
apprentices who graduate from the course), I have found that a student's
progress in class has essentially nothing to do with her/his future progress as 
a KE. If anything, there is an inverse relationship. The AI Training course 
rewards speed. Programming assignments are treated as contests between students 
for the fastest program development, not the most lucid solution. The fastest 
programmers do the best in the course, but the worst when I get them, because 
their impatience and competitiveness handicaps them when dealing with 
gruelingly complex KRep problems, the inevitable political conundrums that crop 
up in their organizations, and the chucking of old misconceived code in favor 
of fresh approaches.
     I've seen half a dozen students now who did abysmally in the training 
course become first-rate KEs because of their persistence. And I've seen half
a dozen flash-in-the-pan go-getters streak through course and win the universal
praise of the course's teachers only to grind to a halt when confronted with
real problems that couldn't be solved with immediate blitzkrieg attacks.
     I now make an effort to work only with the folks who have done the worst 
in the training course - as their projects generally prove the most rewarding 
and sophisticated, and they the most capable as KEs.

     Some specifics:

  We don't use the term "apprentice" because it sounds vaguely demeaning. The 
people we work with are all exceptionally able in some field. They just 
aren't very experienced in AI yet.

  Computer science graduates (who seem to suffer from severely technical 
educations) have the hardest time as apprentices, but the easiest time as
students in the training course. The generalist liberal arts types do better 
as KEs because of their broader backgrounds. CS grads do seem to make
better programmers tho.

  We have found that personality traits often indicate future KEing success
or failure. Cranky, whiney, querulous people put other folks off. As a result,
their acquisition sessions tend to be less fruitful, their domain experts less 
cooperative, their bosses less satisfied, their KE mentors less willing to help.
And their systems suffer as a result.

   The most useful trait for a KE seems to be the desire to learn everything. 
ROMheads (read only memory) always do badly. And people who see KEing as just 
a stepping stone to management (a large step down into the muck in my 
estimation) also do badly. You have to be comfortable with your own ignorance 
to be a KE because you often know so little in the beginning about a domain 
you have to become an expert in.

   The hardest lesson, I think, I've seen apprentices learn is how to read 
people. It's seems to be hard because it's unexpected. There's nothing in
the training course about it, and texts seldom discuss it. 
   Before we meet with a group of people in whose organization we may build a 
system, I tell the apprentice to try to figure out who wants the system and 
why. In the initial interview, that's more important than specs. If the expert 
sees you as a threat to his job, and the manager sees you as a representative 
from the front office come to interfere with his people, the system won't get 
built. Technical problems are easy to solve. Political ones usually sound the 
death nell.

  The tail end of a project (implementation) also seems to be a problem, because
some apprentices seem to want the glory of instituting projects everywhere, but 
not the nasty hardship of seeing them thru to completion.

   And integration/hybridization is always a problem for apprentices because 
they want to do "real AI, pure AI", not diddly linkages between databases and
hostile hardwares and their expert system - which often requires more time than
does constructing the expert system.


-----------------

In answer to the question, When do you become a KE?, here are some ideas we 
use here to gauge our progress as KEs:


-- A "knowledge engineer in training" demonstrates his own expert systems to
   management (to show off his programming skills).

** An experienced knowledge engineer has the USERS of his expert system 
   demonstrate his programs to management to show how useful, user-friendly 
   and well-received his work is.

-- A knowledge engineer in training resents and resists criticism of his code.

** An experienced knowledge engineer welcomes - in fact, actively solicits - 
   criticism of his code - always searching for the best way to solve AI 
   problems.

-- A knowledge engineer in training has a hard time explaining (or 
   comprehending) terms such as "non-monotonicity", "truth maintenance",
   "self-organizing systems", "cognitive emulation", "socratic tutoring",
   "object-based", or "meta-knowledge".

** An experienced knowledge engineer can explain to a layman or an AI guru 
   (in language suitable in complexity to either) the difference between 
   deduction and induction - and can then write programs to demonstrate
   the difference).

-- A knowledge engineer in training works and thinks in only one knowledge 
   representation scheme (rules) and one mode of inference 
   (forward-chaining deduction) and believes he's got expert systems figured 
   out.

** An experienced knowledge engineer can think, speak, and code in ALL standard
   knowledge representation schemes (frames, logic, cases, rules, semantic nets,
   predicate calculus, objects), has experience in deduction
   (forward and backward, non-monotonic) and induction (by example, by analogy,
   by rule fragment), as well as in ancillary fields (human factors, 
   tool design, natural language, hybridization).

-- A knowledge engineer in training understands "works" and "doesn't work".

** An experienced knowledge engineer understands "kluge" and "kruft".

-- A knowledge engineer in training is goal-directed - aiming at deadlines 
   and striving to please his manager by doing things on time.

** An experienced knowledge engineer is NEED-directed - working to please his 
   system's user (and thereby pleasing his boss).

-- A knowledge engineer in training is defensive about his approach to solving 
   a problem and will not accept other approaches.

** An experienced knowledge engineer will overhaul ten weeks of work to make 
   his expert system more useful/graceful/efficient. He wants to build systems 
   in the best way, not necessarily his way.

-- A knowledge engineer in training knows 2 or 3 conventional languages 
   and works in one AI language or tool.

** An experienced knowledge engineer knows half a dozen conventional languages 
   (e.g., cobol, basic, pascal, C, fortran, pl1, etc.) and works in 2 or more
   AI languages/tools (Lisp, Prolog, Art, Nexpert, S1, Ops, Kee).

-- A knowledge engineer in training has never seen a completed expert system
   of his own construction being used.

** An experienced knowledge engineer has seen his expert systems being used (and
   not cursed) on a daily basis, fulfilling their intended functions --
   as well as having seen his own natural language ends, or special purpose
   tools, or demos running.

-- A knowledge engineer in training has projects assigned to him.

** An experienced knowledge engineer prospects for his own projects.

-- A knowledge engineer in training solves problems on the basis of textbook
   learning.

** An established knowledge engineer solves problems on the basis of experience.

-- A knowledge engineer in training thinks expert systems ARE AI.

** An experienced knowledge engineer can hold an intelligent conversation in 
   ANY of the varied branches of AI - from robotics to vision to cybernetics 
   to brain theory to cognitive research to ICAI to language processing.

-- A knowledge engineer in training considers himself "a technical person".

** An experienced knowledge engineer considers himself "a renaissance person".

-- A knowledge engineer in training knows how much he knows.

** An experienced knowledge engineer knows how little he knows.





Dikk Kelly

    About to celebrate my 5th year as a fulltime KE in training and
    it looks like I have a long way to go before I can consider myself
    as experienced!
    
    Keeps life interesting!
    
    pat

    
    How is it that whenever I mosey over to glance at the Euro_Swas_AI
    notesfile I find someone has inserted something in here that I
    scribbled elsewhere for another purpose?
    
    Am I going to get nasty mail messages now saying
    WHAT DO YOU MEAN management is a step down into the muck!
    WHAT DO YOU MEAN maoist re-education camps!
    WHAT DO YOU MEAN Pat's not a big famous internationally idolized
    KE ! (which, of course, he is)
    
    What can I say. Knowledge Engineering is not pretty.
    
    Dikk

    I'm the first to admit that I am NOT an experienced KE, much less
    idolized (other than for my magnetic charm, fatal good looks and
    humble demeanor).
    
    Although I would probably debate some of the finer points of Dikk's
    list of qualifications (and probably will in a couple of weeks -
    up for a beer Dikk?-) I go along with the tone. Good KE's are a
    rare lot, given the diverse skill set needed and the relatively
    short time that the discipline has been around in order to gain
    the experience (wasn't it in 1978 that John McDermit said he R1?).
    I put this list in the same catagory that I put Jeff Clanon's KE
    and ES Project Manager knowledge/skill profile. I think of them
    both as idealized and a proficiency level that I would like to aspire
    to.
    
    Until the time when/if I rise to that lofty realm of "Experienced
    Knowledge Engineer" I will be very content if I am thought of as
    an experienced Software Engineer, gradually becoming a better Software
    Engineer by adding Knowledge Engineering tools to my bag of tricks.
    
    I will take a minute though to discuss the relationship between success
    in the KE training and the ability to do good Knowledge Engineering. I
    readily admit that the former does not guarantee or imply the latter.
    However, I would not say that it precludes it either. Things may have
    changed over the years, but thinking back upon the days when I took the
    14 week offering, names come to my mind like Modeen, Evans, Sutherland,
    Glockenmeyer and Aoki who were absolute wizards in the training and
    have gone on to be wizards in the real world as well. But, ya know
    what they say in the States......  "____ Happens!"
    
    Pat (1 who struggled through training) Roach

    
    Pat, did you mean to say "fatal good looks" or "fatal looks" ?

    Yep!
    

    
    Knowledge engineers are not pretty.

    
    ref .4 and .5  -  
    
    	I don't think he is at all pretty.
    
    J.
    
    	That gets this exchange of notes back to the right level!!