🚀 go-pugleaf

>> Well, I was in software development long enough (15 years) that I 
>> have seen how it is done wrong more times than I can count. I have
>> also seen it done right. My experience is that all it takes to do
>> it right is proper planning and adequate resources. 

>No doubt trying to do it right helps, but that's not enough.  The vast
>majority of software suffers from Creeping Featurism or is Broken As Designed.
>No amount of "good software engineering practice" will fix that.

>You can't have quality software unless you put quality before featurality.

I don't see that we are in disagreement. My contention is that it is 
possible to "do it right". This means, amoung other things, "putting
software quality before featurability". The legal consequences of this
are that there may be legal liability when you do it the other way
(put featurability before software quality). 

The question is how much longer can we as a society accept buggy software.
Sure - I know as well as anyone that with present technology it is almost
impossible to get all bugs out. What I am advocating is that if you release
software with (too many) bugs in it, you may face a competent plaintiff's 
attorney who will use your failure to document your attempts at software 
quality control against you in showing negligence.

Most everyone seems to be of the opinion that since everyone is doing it
(releasing buggy software), it is ok (despite knowing how to at least
minimize the number of bugs). Other areas of tort law have discarded this
type of reasoning. Instead, the law seems to take the position that if
you know how to mitigate a problem, and don't (especially for economic
reasons), you are taking a gamble that the money saved will be greater
than the money lost in litigation. You thus have no reason to complain
when you are found liable for your failure to mitigate the problem.
 
Bruce E. Hayden
(303) 758-8400
bhayden@csn.org