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

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