bugs

[Geoff Canyon]

On Apr 9, 2006, at 5:21 PM, David Vaughan wrote:

>
> On 10/04/2006, at 2:37, Geoff Canyon wrote:
>
>> The question is this: what do you think is the upper limit for  
>> _completely_ bug-free code?
>
> Was your code bug-free the first time you wrote it, no typographic  
> errors or any other changes? Do not answer that because it is only  
> a lead-in to the next comment, that the upper limit is for code  
> which can be made bug free with reasonable economic effort, and  
> that is in my view controlled by the number of people involved.

I'll answer anyway -- nope, not bug free the first time I wrote it.  
The first version had:

   if W is not empty then put item 1 of tRect + W into item 3 of tRect

which of course fails if W is "test."

>
> Your script worked well because you (I presume) conceived the  
> requirement, the design and the implementation and it was self- 
> documenting in that the descriptive text carries import to you  
> which it may not for other people. I take it for the moment that  
> you are also the user.
>
> To the extent that you introduce new actors at any one of those  
> five roles, you will increase the probability of bugs both arising  
> and persisting.

Well, maybe we need to define our terms a bit. The genesis of this  
was the declaration that bug free means code free, so bugs in  
requirements don't really apply. I agree that it's possible for  
requirements to be vague, incomplete, or wrong, but that doesn't make  
a bug in the code.

If you introduce new actors, the requirements might change.

If you find new bugs because you introduce new actors, _not_ because  
the requirements changed, but simply because you missed them the  
first time, that means that the requirements (or your test plan)  
weren't complete.

> I have some small to complex stacks which to the best of my  
> knowledge are bug free, but no-one else uses them, they are  
> substantially undocumented, and the design and usage pattern are  
> perfectly matched, both being through me. I have little doubt that  
> use by other people might expose real bugs and absolutely no doubt  
> whatsoever that those other users would raise as bugs points which  
> I considered to be "obvious" design choices or usages.

If the code meets your needs without fail, then it doesn't matter  
that the requirements are only in your head, they're complete, and  
your code is bug-free. Perhaps it has (numerous) documented (i.e. you  
know about them) limitations.

If the code doesn't behave correctly per your needs, then the code  
isn't bug-free. As the only user, you're the judge. If your code is  
anything like some of the utilities I've written for my own use, the  
requirements are very particular and limited -- as long as it gets  
the job done that needs doing at the moment, that's fine. That  
doesn't mean that the code is buggy per se, but it does mean that the  
code is likely limited and brittle.

If the code were to be used by other people, then the brittle nature  
of the code and lack of documentation is likely to raise issues. In  
addition, their requirements might be different than yours, in which  
case the code doesn't meet the requirements any more.

> I have also a fairly complex stack with at least one obvious bug  
> but I know about it and work around it because that costs me less  
> effort, even on a regular basis, than investing in fixing that  
> stack compared with my other development priorities which are  
> themselves way below my other life priorities (reiterating for  
> those who have not read it before that I do not develop software to  
> order nor for product). Eventually, it will irritate me enough and  
> I will have the spare time so I will fix it.

Then obviously it has a bug, but since you're the only person who has  
to live with it, it's obviously your call whether it needs to be fixed.

> The last part was a bit of a digression. The main answer is that  
> bugs arise less from code size than from the count of actors in the  
> five steps from concept to use. A sufficiently complex project  
> conceived, developed and used by a single person will merely not be  
> finished while the development bugs are being ironed out. :-)

Then someone should be able to step forward with some large piece of  
code written by them, for them, which is completely bug free.

Likewise, there should be no one able to step forward with a piece of  
code of any size beyond tiny that is written by someone for general  
consumption that is completely bug free.

As far as I can see, the code I posted -- all eight lines of it ;-)  
-- is bug free for use by anyone. The requirement is reasonably  
clearly stated, and it will do what it says no matter what, given  
proper input, and given improper input it won't die.

I invite everyone (famous last words) to prove me wrong. If the code  
stands up, I'll try to find something twenty to thirty lines long  
that I'm happy with, and toss that out.

regards,

Geoff