Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

[REBOL] On "What is a bug?" [was Re: WYSIWYG programming]

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. > > > > 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 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-