bugs

[Geoff Canyon]

1. The requirements simply say to display the date -- the date is  
displayed. If non-modality is needed, that should be in the  
requirements.
2. It is certainly possible to put the code someplace inappropriate,  
but I think for the purposes of this assignment we can assume that  
isn't the case. To assume otherwise would be like if I say a car I'm  
selling runs fine and you say, "Not if I drop it out of an airplane."
3. Also a requirements issue. At the time the code is called, it will  
display the date. If the screen saver activates five minutes later,  
thus hiding the date, that's not a bug.
4. Dropping the car out of an airplane. The code _as presented_ is  
bug free, I believe.

I think it's important to note that I don't consider this code to be  
presented "out of context." It is the entire program, in one visible,  
enabled button, on the only card in one stack. It's not very useful,  
but for the extremely limited functionality that it provides, I think  
it is bug free.

My point is that I think it _is_ possible to write bug-free software.  
Not that I have ever done so, of course ;-) Writing bug-free software  
requires two things:

First you need a clear and complete set of requirements. Note that  
there is no equivocation there. The requirements must be totally  
clear, and absolutely complete. The requirements must be such that  
any reasonably intelligent person can sit down, read them, and then  
answer _any_ question about what the software is to do. Furthermore,  
such requirements, should map cleanly to a set of tests. The mapping  
should be bi-directional: given the requirements you should be able  
to produce the tests, and given the tests you should be able to  
produce the requirements.

I have never seen such requirements, nor really anything close to it,  
and that's okay. Requirements like that would be exceptionally hard  
to write, and most people are willing to deal with the issues that  
come with easier-to-write vague specifications.

Second, you need time and effort to work against those requirements.

There is an article on the Space Shuttle software that I find  
interesting:

http://www.fastcompany.com/online/06/writestuff.html

Quoting: "Consider these stats : the last three versions of the  
program -- each 420,000 lines long-had just one error each. The last  
11 versions of this software had a total of 17 errors."

The part I don't get is: if you have it down to just one bug, how  
hard is it to find and fix that one bug?

regards,

Geoff

On Apr 8, 2006, at 11:21 AM, Mark Wieder wrote:

> Geoff-
>
> Saturday, April 8, 2006, 12:21:38 AM, you wrote:
>
>> So tell me what could go wrong? ;-)
>
> In addition to the "system" date already taken care of,
>
> 1. The date is displayed in a modal dialog, which makes further use of
> the app impossible until it's dismissed.
> 2. The mouseUp handler is never called. Did you mean to put it into a
> button instead of an unlocked field?
> 3. I brought up the answer dialog at 11:59PM. When I went back and
> checked it five minutes later it still had yesterday's date on it.
> 4. Displaying the mouseUp handler out of context doesn't guarantee
> that it will run without problems. What if your mouseUp handler is in
> the stack script and another mouseUp handler in a button intercepts
> the message and doesn't pass it? You'll still have some debugging to
> do in order to figure out why the date isn't displayed.
>
> The point of all this is not that I'm nit-picking (I am, of course).
> The point is that the ambiguities in the requirements can provoke any
> number of equally valid (and equally wrong) responses. If I had wanted
> the date displayed in the upper-right corner of the main stack and
> continually updated, that still would fall under "display the date".
> So would the case where I wanted a stack to function as a cgi app and
> display the date as a string sent to stdout.
>
> -- 
> -Mark Wieder
>  mwieder at ahsoftware.net
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>