Programmers and error messages?

["Geoff Hart (by way of \"Eric J. Ray\" <ejray -at- raycomm -dot- com>)" <ght -at- MTL -dot- FERIC -dot- CA>]

Chuck Martin has several issues about the book "Developing Windows
Error Messages" (O'Reilly, ISBN 1565923561):

<<First, it's claimed target audience is programmers. Why, oh why, do
the authors and publishers want to perpetuate the myth that
programmers should be the ones to write error messages?>>

Perhaps because--like it or not--programmers are the biggest single
source of error messages... pun intended. While I agree with you that
it would be better if we techwhirlers did the writing, the reality is
that this isn't yet the industry standard. (If it is, then I've got
to say that maybe the programmers should take back the job, because
we aren't doing such a marvelous job of it.)

<<Second (and this is a more root issue), I'm a firm believer that
error messages are bad... I agree with Cooper when he says that good
software design will alleviate the need for nearly every possible
error message. >>

Someone or other's law: "Good computers don't go down." Murphy's
corollary: "There are no good computers." <g> I guess it all depends
on what you mean by "errors". If you mean you should never see an
error that says "divide by zero error: please feel free to curse the
programmer, but it won't help because you just lost your morning's
work... deal with it", then you're 100% correct. If you can describe
that kind of error, then you can certainly program it out of
existence through an "error check". (Simplistically: If y = 0 then
goto "you entered the wrong denominator. Please try again" else a =
x/y.) If you mean that good software design can eliminate user
errors, then that's simply not realistic. On my best day, I do things
that make me say "d'oh!", and I suspect I make a lot fewer errors
than most of my colleagues here.

<<I have been actively involved in the design of the software
interface, and one of my goals was not only to make the interface
understandable, but to advocate design that would avoid error
messages by not allowing the users to take actions that would result
in errors.>>

I'm in the same situation now, and it's wonderful. I know it's
wonderful, and that it's relatively rare. The trick is to make an
effort to move the industry standard in that direction. Many small
steps gets you to the goal just like one big jump, but it's a lot
easier to take the small steps.

<<While I can see that the intentions of this book are good, I think
it's ultimately a step backwards, both in terms of advancing software
design principles and of technical communicators having a voice and a
role in the software development process.>>

OTOH, think of it this way: If you write a book for programmers that
says "you shouldn't read this book because it's the techwhirler's
job", how many programmers are going to read it? If you write a book
for techwhirlers only, how many programmers in companies where the
programmers write error messages will read it? Seems to me you should
just ignore the intended audience and evaluate the book on its own
merits. In fact, write your own book review for Amazon that says
"although intended for programmers, anyone involved in software
development (especially techwhirlers) would benefit from reading
the book." Not only do you help to set the record straight, but you
also might win one of their gift certificates. Fair deal?

I'd go one step further. Read the book, and send your comments to the
folks at O'Reilly. From what I've seen of their books (and what I've
read in reviews), they care enough to choose people who know what
they're talking about and give them editors who can help them say it.
Perhaps version 2 of the book will include changes along the lines
you suggest.
--Geoff Hart @8^{)}
geoff-h -at- mtl -dot- feric -dot- ca

"Patience comes to those who wait."--Anon.

 From ??? -at- ??? Sun Jan 00 00:00:00 0000=