Software support methodology (was Re: Mach from mt Xinu)

[John G. DeArmond]

allbery at NCoast.ORG (Brandon S. Allbery KB8JRR) writes:

>No argument.  Aside from the fact that having to staff for this can make it
>real hard to get support for *real* problems (i.e. the current problem with
>ISC).  Back when I was evaluating the then-new Informix-SQL 1.10, I had to go
>through a number of levels of idiots who were convinced I was typing in
>illegal SQL statements before I got one who understood that the fact the
>example in the manual was causing SQL to dump core was in fact a bug.


It seems to me that the software industry could afford to do a technology
swap with the emergency medical guys.  Specifically, software support
should be treated like an emergency room.  There, when things are not
busy, the interns (roughly equivalent to beginner programmers) handle
the routine stuff and specialists are called in as needed for the special
cases.

In times of emergency (the software analog of a new release, perhaps), a 
different plan, called a triage, is implemented. In this plan, senior
medical personnel meet the incoming and sort them  into three groups: a)
the obviously terminal or soon to be >>AND<< those for which saving would
consume too many resources, b) the minor injuries, and c) the people
needing immediate help and whose chance of recovery is great AND whose
immediate care will not consume too many resources.  (God, I'd never want
to be in that decision making position) 

The software analog to a) could be the user who calls to ask what "root" is.
For b), this could be the person who reports that after setting up a 
pathological situation, write(2) puts the bytes out but returns 0.  C) of
course, is the knowledgable user/programmer who has uncovered a problem
("I write a zero to a certain place in U and become root") that is
potentially fatal but for which a fix MUST be had in order for the product
to be used.

Note some key features of the medical analog:

a)	During normal times, junior people make the initial assesment but don't
	hesitate to call in specialists at the first indication.  Note, however
	that these junior people ARE doctors and not janitors or receptionists,
	the people commonly found on software tech support lines. (hey, if the
	shoe does not fit, don't get mad.  By broad brush has holes in it for
	you good support people.)  

b)	That senior specialist may (indeed probably) be the leading expert in
	his field or at least at the facility.  The good doctors don't get to
	lounge around behind closed doors like senior programmers tend to do.

c)	During triage, there is a plan that has been practiced and perfected
	that all personnel know about and adhere to.

d)	During triage, all skilled personnel are applied to the emergency 
	situation.  None of this "that's not my job" or "I'm too {senior,good,
	highly paid} to do that." BS.  This does not, of course, mean that
	the hospital is gutted of doctors; indeed careing for the other patients
	is part of an emergency plan.

e)	When the emergency room fills to capacity, victims are diverted to 
	other facilities if possible.  What a novel thought for the software
	industry.  Actually having someone outside the company capable of 
	rendering servce.  Perhaps a large VAR with its own customer support
	staff.

f)	The people with minor problems *as judged by a senior technologist*
	simply have to wait for the emergency to pass or get help elsewhere.
	We have a leg up on the medical business in that we alrealy have 
	established alternative avenues for support such as Usenet, Compu$erv
	and so on.

Of course, implementation would require a good bit of thought and work
if for no other reason than the psychological issues involved.  There's
not much to loose, however, since people now say something nice about
their software vendor about as often as they do about their used car
salesman.

Before someone knee jerks that this plan would not work because vendors
can't charge the way hospitals can, consider that a) vendors get paid up
front which would be like some special hospotal wellness fee, and b) when
software companies start having malpractice insurance, pro bono cases,
FDA regulations, medicare/medicade (medisoft? :-), cost  containment, and
local government intereference (how many software vendors have to justify
new products the way hospitals have to justify new beds?), then I might 
agree. There is the difference in costs.  The fact is that good doctors
and good programmers are not paid much differently. 

What this industry needs is a good shot of innovation instead of the 
same old bleating about piracy, support, and so on.

John


-- 
John De Armond, WD4OQC        | "Purveyors of speed to the Trade"  (tm)
Rapid Deployment System, Inc. |  Home of the Nidgets (tm)
Marietta, Ga                  | 
{emory,uunet}!rsiatl!jgd      |"Politically InCorrect.. And damn proud of it