[REBOL] On "What is a bug?" [was Re: WYSIWYG programming]
From: joel::neely::fedex::com at: 30-Oct-2000 9:01
> The problem of information loss you point out with none in
> parse more points to a bug...
If calling it "a bug" instead of "a poor design choice" or "an
implementation oversight" gets it fixed, then fine! I try not
to call things bugs unless I can point to a specification that
is clearly violated. That way, labeling something as a bug
can be objectively defended or refuted.
Other folks seem willing to use the term "bug" for "something
I disagree with" or "a prior decision that looks worse in
hindsight". That way, labeling something as a bug can simply
degenerate into one person's opinion versus another.
> > > By any other name: BUG. Yes, software has bugs. Bugs
> > > are frustrating.
> > Yes, but it's more frustrating to be uncertain about
> > whether something IS a bug! I've seen disagreement on this
> > list between experienced REBOL programmers over whether a
> > particular piece of behavior is a bug or not. ..
> Pioneers often have to go forward with out a perfect Rand
> McNalley road atlas and triple-A. :)
Here's a key issue of disagreement in philosophy.
When I set off into an unexplored forest, there is no way IN
PRINCIPLE that I can know the lay of the land, what kinds of
critters (and bugs!) live there, etc.
When I set out to write a computer program (including an
implementation of a language) I most certainly CAN begin with
a specification (written by me and/or others) that states
what I'm committing to construct. Once I've constructed an
artifact, it is possible to address objectively the issue of
whether I've constructed what I said I would.
This allows a very useful "separation of concerns" (that phrase
due to Dijkstra):
1) the *technical* concern of whether I've built what I agreed
2) the *political/psychological* concern of whether the original
specification adequately captured what someone desired.
I know of no better way to survive, either as an independent
consultant or as a corporate developer, than to keep these two
issues separate. If I build something that conforms to spec that
my client/user and I agreed upon, and then the client/user says,
I didn't mean that!
, or "Oh, that's not it after all!", then
I can respond, "OK. Let's sit down and work out the spec for
revision." OTOH, if I build something and the client/user can
show me that it doesn't conform to spec, then I say "I'm sorry!
let me fix it!" (In the case of an external client, he pays
in the first case and I pay in the second!)
That said, there is certainly an aspect of computing/programming
R&D that involves trying things that haven't been tried before,
to see if one can build a better mousetrap. IMHO, this kind of
presents an even MORE URGENT need for
having clear specs. If the result doesn't make the explorer
happy, it is VERY IMPORTANT to be able to determine whether:
1) the "wrong thing was attempted", but attempted correctly,
2) the "wrong thing was build", but if it had been built as
specified, the attempt would have been deemed a success.
The other benefit (in both production and R&D scenarios) of a
specification is that a (well-written) specification can often
be discussed and reasoned about as a means of finding problems
and predicting outcomes, before the code is written. I have
often had conversations with clients/users of the form,
This requirement on page three is in conflict with this
requirement on page five. Which would you like me to do?
or of the form
This requirement on page two, combined with this requirement
on page four, means that the product will do this... Is
that satisfactory, or do we need to make some changes to
When such discussions are conducted with the right attitude on
both sides, they usually produce a higher quality spec, a better
working relationship (for when the real bugs do appear!), and
a better quality product.
Respectfully submitted for your consideration.