🚀 go-pugleaf

eoliver@ralph.cs.haverford.edu (Erik Oliver) writes:

>Proving software correct is extremely difficult to do, and making sure
>that there are no "bugs" is even harder.  For example, in the
>IBM-Compatible world, it is very hards to anticipate all of the possible
>setups that might have an incompatibility with your software.  If my new
>product XYZ-Works doesn't work on a SuperDuper486DX/2 is that
>necessarily reflective of a bug in my software or a glitch in some part
>of the SuperDuper product?

Agreed - you can't get all of the bugs out. You can however get the major
ones out, and the minor ones down below a certain, prespecified level.
I am not advocating proving all software correct. I am just advocating
somewhat well documented software quality control/assurance procedures.

>Because of the variety of IBM-Compatible products out there testing for
>every configuration is unrealistic, if not impossible.  Even in the Mac
>world, there are problems that occur because of interactions between
>INITs and CDEVs with applications.  Are these bugs?

I think that depends on how common the hardware and hardware combination
is. If the hardware is anywhere close to common, then I would contend
that it is a reasonable to test a major product on all of the common
hardware. 

I also would contend that once you have serious problems with a specified
hardware combination (with previous releases or products) then you may
potentially have a duty to duplicate that hardware combination for future
QC testing.

Obviously, you have a resource problem here. IBM can afford to basically
test almost anything imaginable (so why didn't OS/2 work on many non-IBM
platforms?) A small company can probably only afford to test on a limited
number of platforms and combinations.

>I think that if the manufacturers make good faith efforts to keep their
>product working and put out bug releases that is about as much as we can
>expect.  Personally I think that the software produced by organizations
>like the FSF is better than a lot of commerical stuff because they are
>not afraid to keep updating their product and release slews of fixes as
>necessary.

I disagree. We have the capability today to set an acceptable bug level
before the release, then not release until we have reached that level.
That isn't happening in many cases. Either we aren't setting the level,
or if we are, we are shipping before we get to that point.

Bruce E. Hayden
(303) 758-8400
bhayden@csn.org