Taking risks on software (ISC)

[Vernon Schryver]

In article <935 at zoom.Clik.QC.CA>, marc at Clik.QC.CA (Marc Boucher) writes:
> ...  I have been
> stupidly asked many times for the "exact error message" with to the word
> precision! so that the ignorant interactive employee could look it up in her
> miracle problem solving database.
>
> Marc Boucher, sys/netadm @ CLIK Telematique Inc - marc at clik.qc.ca
> 5144668932_home 5149337161_clik 5149332164_fax  - Postmaster at clik.qc.ca

Without intending to comment in any way about ISC support, getting the
exact text is vital.  How many times have you been told "x is broken" only
to discover that "x" had nothing to do with anything but ideas about how
"y" works, where "y" is what failed?  Bug reports tend to contain purported
error messages resembling the most common error message, regardless of what
was actually on the screen.  Perhaps this is because things are often not
written down, and people can remember only what we (think we) understand.

When someone asks my help, I insist on the exact error message and the
complete, undigested, unanalyzed symptoms.  When I forget, everyone looks
stupid and gets angry.  E.g. last week at my day job (nothing to do with
386's or ISC) a customer, a support person, and I wasted hours of long
distance phone time arguing about how and whether 'cat foo>/dev/tty'
discards ESC characters, while had I asked, the problem was obviously an
`stty ixany` in /usr/spool/lp/interface/*.

Similarly, a useful stratety for RTFM questions is to tell the caller to
never mind that you wrote the manual, that your copy is not handy, and ask
to be read the relevant section, so that you can "figure out" the answer.
The lazy soon find others to hassle, the inexperienced discover they can
read the manuals, and the answer is given.  At the cost of looking senile,
you have avoided insulting the caller.

Vernon Schryver
vjs at calcite.uucp