Check it out: http://www.*-*-*.com/

   ____    _    ____      ____  _____
  |  _ \  / \  / ___) __ | ___)(_   _) Don Schullian

  |____//_/ \_\(____/\__/|_|     |_|    www.DASoftVSS.com
  ___________________________________   www.basicguru.com
      Vertical Software Solutions

Sometimes a "non-critical" bug does not need to be dealt with
immediately.  It can simply be catalogued and fixed at a more convenient
time.

In very large programming projects, it doesn't pay to immediately fix a
bug and release a new version.  This is particularly true after the
initial release of a product.  Instead, you fix each bug as it's
identified, but wait a while before shipping the bug fix (if none of the
bugs are critical).  Otherwise, the expense of shipping 10 to 15
different versions can overwhelm you.

With stuff like shareware where distribution is entirely internet based,
it's easy to to quick updates like this, but when you have a customer
base that's only 60% on the internet, you learn to time things better to
reduce costs.

--Dave

Regards,

Jimmy Shoehorn

When I was general manager of a software firm, our software was thir{*filter*} or
four{*filter*} major modules, with perhaps thirty separate programs per module -
about one million lines of source code altogether. When we found bugs, we
needed to record them for several reasons:

1. So that the support people and users could be aware of them. We had
support people in two cities, so keeping both groups informed was even a bit
more difficult than were they all in the same room.
2. So that programmers doing a customized ("tailored" is a preferred
euphemism) version of a program would know there was a bug in the code they
were working on and could do a temporary patch.
3. Because a "bug" in one program like a print report or a screen inquiry
may not be a bug in *that* program - it was, in fact, a bug in a different
program which only shows up in a later program. We would then need to find
"all the bugs in a certain program" so we could make one fix without
skipping another fixable problem, or worse yet, introducing a new bug
because of a previous fix. Not to mention, fixing the bug in one program may
require changes in other programs *down* the processing stream.

As Dave Navarro pointed out, when you have a large user base, an immediate
release for every little fix is an administrative nightmare; and when as
many as 90 percent of the users never run into the bug, it is a hassle for
them as well, because now they have to make fresh 'program file' backups. (I
wish pc-software vendors had a mainframe 'ZAP'-like utility or could let you
just re-link your program for small fixes instead of requiring a complete
release. Then I could just back up the 'zapfile' and not bother with the
full program backup).

As a last case for using software to track bugs, consider the task of
assigning 'fix duty' in the "bug is in program one, but you don't see it
until you've run programs two, three and four" situation.  You need to
assign all fixes in the family to the same person, as they often cannot
technically and almost never logistically be done 'in parallel' and must be
done 'in series.'

At my firm, it was not inconceivable that there could be at ony one time as
many as two hundred individual programs requiring action; while some people
might be able to remember all that, I never could, so I used database
software to track it for me.

Michael Mattias
Tal Systems
Racine WI USA

<snip>

   ____    _    ____      ____  _____
  |  _ \  / \  / ___) __ | ___)(_   _) Don Schullian

  |____//_/ \_\(____/\__/|_|     |_|    www.DASoftVSS.com
  ___________________________________   www.basicguru.com
      Vertical Software Solutions

What I *do* like is an online known bug database, with info on how to
reproduce it, a tech discussion, and possible workarounds.  That
really helps.