jgd@Dixie.Com (John G. DeArmond) (03/18/91)
allbery@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
peter@ficc.ferranti.com (Peter da Silva) (03/21/91)
In article <8305@rsiatl.Dixie.Com> jgd@Dixie.Com (John G. DeArmond) writes: > 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, You mean like an HMO? Our company switched to an HMO a year or so back, and boy am I glad I took the option of paying more for major medical coverage. It was worse than software support, if only because of the seriousness of the situation. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"