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
[EMAIL PROTECTED]
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
