bugs

[David Burgun]

On 8 Apr 2006, at 12:07, David Vaughan wrote:

>> So tell me what could go wrong? ;-)
>
> I realised while cooking the salmon this evening (crocodile being  
> off the menu) that Geoff had inadvertently provided a wonderful  
> case study on bugs. Any link to Geoff in the following is purely  
> coincidental and nothing to do with him at all :-)
>
> Once upon a time, an aspiring programmer wrote:
>>> on mouseUp -- display the date
>>>   answer the date with "OK"
>>> end mouseUp
> and released it as shareware.
>
> His American audience loved it. He received five star ratings on  
> Versiontracker and plaudits on download.com, so impressed were  
> users at being able to load an application, click a single button  
> and see the date. Most impressive of all, it looked bug free.
>
> Then, some old bloke from Australia gave a negative review,  
> declaring the code contained a bug in that the information "4/8/06"  
> for 8 April was simply wrong. A Frenchman wrote to say that the  
> format should be "060408". Both complained that this was a clear- 
> cut bug about which the developer should have known before  
> releasing the software with the documentation "Displays the date".
>
> Relying on precedents in  "Gutnick v. Dow Jones", they observed  
> that even though the software was uploaded in America to an  
> American server, it was published in Australia and France where it  
> was read, and therefore subject to those foreign laws of fitness  
> for purpose, with which any judge in those jurisdictions would  
> agree ;-) Therefore, we have an indisputable bug in even this  
> simple application.
>
> Now that we know that no code is bug-free, two issues arise, one of  
> morality and one of money.
>
> Has the programmer committed an Immoral Act by publishing this  
> software with a bug about which those foreign users believe he  
> should surely have known?
>
> What commercial decision should the programmer make? Add 33% more  
> lines to the code ("set the useSystemDate to true") just to cater  
> for foreign system dates, or add one word to the documentation so  
> that it says "Displays the U.S. date"? One action will cost more  
> than the other, and either will cost more than doing nothing and  
> restricting his target market. Perhaps he should focus his  
> development energies on his upcoming product "Displays the time"  
> which he expects to sell at twice the price?
>
> So, it appears that
> - bugs happen, even when they are sincerely believed not to exist  
> and with the best will in the world, and testing which seemed  
> comprehensive at the time;
> - money matters in commercial decisions without greed per se being  
> a factor;
> - the morality of the developer is not questioned by the discovered  
> bug.
>
> Perhaps RunRev has more bugs than it should have. That is something  
> I do not know, but Lynn may on industry benchmarks. Regardless,  
> bugginess is a relative question.

The real problem here is if the marketing department get ahold of it,  
they will make it into a "feature" ! e.g. this Application is  
"supposed" to tell you the time in the USA, it's so cool you don't  
have to figure it out for yourself, thereby cutting out the rest of  
the world from the product. Eventually when the US market slows down,  
they add a preference to allow the time to be shown in local time,  
call it an upgrade and charge everyone for the privilege of fixing  
the bug!

How many times you seen that happen???

All the Best
Dave