Re. Deciphering cryptic help messages

[Geoff Hart <geoff-h -at- MTL -dot- FERIC -dot- CA>]

  David Castro asked how to fix incomprehensible error
  messages when the folks who wrote them are unavailable to
  explain the text. Two thought occur to me:

  1. (Impractical?) If you've got a beta testing (or
  technical support, or quality assurance, or some other
  synonym) group, ask them when (in what situations) each
  numbered error has been reported by testers. This may give
  you enough clues to reconstruct the cause of the error, and
  thus the meaning of the message. I called this impractical
  because that's a lot of work, and your deadline is probably
  too tight; moreover, you may not have beta or other results
  since these are occasionally unavailable for first
  releases.

  2. (Likely) Obtain a copy of the product specifications and
  see if somewhere, some enlightened soul has specified the
  coding scheme for the error messages. (Ex: Errors from 1 to
  100 indicate disk I/O problems, from 101-200 indicate
  invalid data entry, etc.) You may strike gold here, or you
  may just find a few helpful hints. If you understand the
  programming language, you might also be able to extract
  some meaning from the _comments_ added to the source code,
  particularly if the development manager enforces good
  commenting practices (i.e., embedding explanations for
  program logic, variables, etc. directly in the source
  code).

  If none of these ideas work, and you're truly desperate
  (and your job is hanging on the outcome), kidnap the
  experts for a dinner date and grill the propellerheads
  while they gorge themselves on their favorite food. (Extend
  the work day? Even engineers have to eat sometime, so
  consider ambushing them at lunch instead if this is more
  convenient.) Most importantly, start putting procedures in
  place now so that you don't find yourself in the same
  situation next time. I'm doing this now at FERIC, at the
  "we have a neat idea for adding programming to our
  portfolio of tricks" stage, and the research director was
  astounded that nobody had ever thought of this before.
  Nobody at FERIC, leastways! <grin>

     --Geoff Hart    @8^{)}
     geoff-h -at- mtl -dot- feric -dot- ca

     Disclaimer: If I didn't commit it in print in one
     of our reports, it don't represent FERIC's
     opinion.