- Bob - said:
Well, I didn't check as of late but I recall Win2K being released with
10,000 known issues. The same tactics and strategy are still in place
at MS.
Not exactly the same as a cautious company debugging software to the
best of its ability then finding bugs in the field which need repair.
Have you ever been part of the software development team of a
non-trivial product that couldn't wait indefinitely for release?
If so, and if you were one of the major developers, then unless your
team spent a -lot- of time on strong designs, preconditions and
postconditions, logical proofs, and other elements of Zero Defect
Programming, chances are excellent that you've released your code with
known bugs -- possibly with *many* known bugs.
*Every* real development team that I've ever interacted with
has prioritized their known issues. Some teams had strong policies
about not releasing software containing problems of more than
a certain assessed severity; others just did what they could to
get the best practical product out by the fixed deadline. But they
all had their bug lists, and even in the best companies some of the
bugs wouldn't get fixed the same year; some bugs would end up
never actually fixed and would just be found to have "gone away"
when something else changed.
For example, I worked as the sole active software developer on
a scientific package (several years ago.) I kept comprehensive
bug lists -- everything I found wrong, I created a report for.
Some of the earliest bugs that I found were still there when
development was abandoned about 3 years later.
Does that mean that I was a bad software developer who should never
have released anything until the bug-list was completely clear?
(If so, perhaps I should have been less scrupulous as to what
I recorded!). But this was a scientific program: for some of
the bugs I recorded, there is (still) no known solution for.
For example, for the particular kind of values we were summing
together, there is no known way to find the global minimum of the
equation (which was important to the program). There is no known way of
finding general global minima even in 3-dimensional space, and this
program was working in 32 to 84 dimensions. Indeed, one can prove that
*in general* there *is* no way of finding global minima even just in 2
dimensions. So the task might not have been -possible-, but
perhaps if some world-class complex function analysts had worked
on it for a couple of hundred years, they might have been able to
find the global minima of those -particular- equations. So down it
went on the bug list: the program was incomplete and could
produce potentially incorrect results; there might
in practice be a -better- search method, and there might in theory
be a complete search method. Mind you, the hypothetical
complete search method, if it existed at all, might have required
about 10 the the 85th calculations... But it was there on the
to-fix list, with an action item of hiring a bevy of top
mathematicians to spend several decades focused narrowly on improving
one small portion of the program functionality.
Some day you should look at the mathematics of proving program
correctness (even restricting to cases where the "right" answer
to each subsection is known ahead of time.) And look at industry
standard bug rates. Even just one bug per thousand lines (very very low)
applied to a program the size of MS Windows (millions of lines of
code) implies thousands of bugs -- and even with the best industry
tools, teams that can achieve bug rates that low are extremely rare.
Companies can be very cautious and -still- have large numbers of
known bugs, if their code base is large enough.
