refresh_callback: zone , after bind9 upgrade

[Barry Margolin]

In article <9kv8qf$cbe at pub3.rc.vix.com>,
Brad Knowles  <brad.knowles at skynet.be> wrote:
>	If you really feel this strongly about it, then I'd suggest you 
>stop bitching, and start reviewing some BIND 8 code, so as to bring 
>forward all your favourite error messages.  I'm sure that code 
>contributions would be more than welcomed by the ISC and Nominum.

I don't have any favorite messages.  Like I said before, BIND 8's messages
also were terrible.  It's just that BIND 9's seem even worse!

>>  I don't think they should have reused the old wording.  I think that since
>>  they were doing a complete rewrite, and had to compose new error messages,
>>  they should have composed understandable ones.
>
>	This is a different issue altogether, and does not relate back to 
>your previous statement:
>
>		You guys are presumably intimately familiar with most of
>		BIND 8's error messages.  You could have simply reused
>		the old wording in cases where they applied, but instead
>		you decided to come up with new wording from scratch.

I said "could have", not "should have".  I specifically said that I
presumed that the people writing BIND 9 were already familiar with BIND 8,
either as developers or users.  If that presumption were true, it wouldn't
have required any special effort to use similar messages, like your earlier
suggestion that they go through BIND 8 writing down all the error messages.

My point all along has been that they shouldn't have to go to any special
effort to produce messages better than BIND 8, or at least the same.
Either they already know BIND 8's messages, in which case they could just
reuse them, or they have to compose new messages from scratch, in which
case they should compose understandable ones.

>	When you get an entire team of people involved in doing a project 
>like this, and they get into serious "hack mode", it is not at all 

Professional software development should not be done in "hack mode".

>unusual to find that techies naturally write error messages for other 
>techies (i.e., mostly their co-workers on the team), and even if you 
>ask them to spend a lot of time to try and make the wording as 
>crystal clear as possible, the result is frequently still extremely 
>opaque and obtuse to any outsider (including people like you and me).

When BIND was first written, only techies used it, so it's understandable
that the error messages were targeted to them.  The Internet user base has
changed dramatically in the two decades since then, and the authors of one
of the most critical pieces of software should take that into account.

>	This is life.  You can either learn to deal with it, and do your 
>part to help fix the situation, or not.  The choice is up to you.

So if someone does something I think is silly, I'm not allowed to point it
out?  I'll bet most of you don't simply "learn to deal with" all the
stupidity that comes out of Microsoft.

>>  It takes no more time or resources to compose understandable error messages
>>  than to compose cryptic ones.
>
>	Not at all true.  Composing error messages that are actually 
>generally understandable is one of the most difficult tasks in 

I'm not asking for bon mots, just plain English.  "Error while performing
SOA query to refresh <domain>: <error message>" does not require the skills
of a technical writer.  Anyone who can't do this should not be in the
business of writing software with a user interface.

An error message that simply says the name of some internal subroutine that
the user has never heard of and can't possibly know the purpose of is the
exact opposite of this.  Requiring users to use the source to understand
tracing messages is not unreasonable (although I wish there were a better
way), but requiring them to read the source to understand common error
messages is.

-- 
Barry Margolin, barmar at genuity.net
Genuity, Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.