[conspire] Risks of automation

[Rick Moen]

Quoting Ross Bernheim (rossbernheim at gmail.com):

> Rick,
> 
> A point stressed many times in the 33S training I took in the Army was not
> to rush the observation phase. Make sure you collect all the symptoms.
> 
> By not collecting all the symptoms under all operating modes you could
> be led to believe there was a different problem than the real one.It
> was surprising how many flunked out of the course for this reason.

Yes, very much this.  Good point, so thank you, and my thanks to the
U.S. Army's Military Occupational Specialty trainers.

A fellow on the SF-LUG mailing list wanted to have their recent Tuesday
meeting devoted to teaching troubleshooting.  'Course, the guy
suggesting this would not be at the top of my list of people to organise
that or anything else.  In this case, he wanted someone _else_ to 
magically put that together at the last minute.  Not sure it happened,
but more than likely not.

But teaching the principles of diagnosis seems a great idea, and I
actually pointed the SF-LUG people to this thread as a modest example, 
saying it typifies my personal favourite way to teach that subject,
which is to dissect a situation where I screwed diagnosis up.  ;->

> Expertise helps in understanding how the piece of equipment or system 
> operates helps insure that you don’t miss anything.

I would say that expertise makes that _easier_, quicker, more certain.

Just careful observation and logic -- if careful enough -- I would
maintain will always get you there.


Anyway, I've been spitballing (just in my head, until now never in
writing) about principles of troubleshooting.  Off the top of my head, a
few:

o  Observe all symptoms (as you said), and keep detailed records.
o  Where possible, establish known-good and known-bad components.
o  Where possible, use simple tools with reliable, known traits.
o  Make sure you are extremely clear on what the problem _is_.
o  Any candidate explanation must account for all the symptoms.
o  Don't trust any candidate explanation you haven't tested.
o  Distrust coincidence.
o  Always remember that causes are only imputed, not an empirical reality.
o  Be careful not to change more than one thing at a time.
o  See if you can eliminate groups of possible causes, e.g., 
   to test whether it's hardware or software.
o  Lateral thinking often wins.