On "What is a bug?" [was Re: WYSIWYG programming]
[1/2] from: joel::neely::fedex::com at: 30-Oct-2000 9:01
[rebol-bounce--rebol--com] wrote:
> 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.
<<quoted lines omitted: 5>>
> 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
to build,
vs.
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
exploratory programming
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,
or
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
the specification?
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.
-jn-
[2/2] from: jeff:rebol at: 30-Oct-2000 6:21
Howdy, Joel:
> 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 "exploratory programming"
> presents an even MORE URGENT need for having clear specs.
1. Specs are good. No need to argue for their utility.
2. REBOL doesn't have a spec to publish, though we've
published a variety of spec like materials for different
portions of REBOL. Also, right now REBOL Tech. doesn't
have the luxury of time and resources to produce a
publishable spec.
3. People often flame us for not publishing a spec.
4. Unfortunately, that's the way it is. Generally, on
tricky definitional problems we defer to Carl, our human
spec.
We try to do our best to identify bug from misunderstanding
and hope no one has hard feelings when it's the latter. The
engineering team is expected to produce an internal spec
before (or while) implementing a feature or substantial
change to REBOL. As mentioned above, we've actually
published a few of these-- the module spec, the serial port
spec, command line interface changes spec.
I know where you're coming from, though, but that's about
all that can be said about that.
Cheeers!
-jeff
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted