Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))

[softeng3456@netscape.net (soft-eng)]

Shayne Wissler <thales000@yahoo.com> wrote in message news:<fZQwa.855043$F1.107665@sccrnsc04>...
> Robert I. Eachus wrote:
> 
> > Or it may be impossible.  There have been several times I have thought
> > of creating a bug tracking system that tracks how many bugs are caused
> > by a previous "bug-fix."  The number of such bugs for each earlier bug
> > is a major determinant of when existing software has become too
> > "brittle" and has to be replaced. 
> 
> I think what it indicates is that the development methods used are 
> brittle--which leads to the brittle code. If you see the secondary bug to 
> primary bug ratio consistently rising, the first thing to do is ask 
> questions about who is managing the project, not about the software itself. 
> Even the best software will have bad ratios if the people working on it are 
> sloppy.
> 
> Although it's not easy, I don't think it's rocket science to be able to make 
> consistent progress. If, for every bug you hit, you always investigate why 
> the bug happened, and then modify your approach accordingly, I don't think 
> you can get into the spiral you're referring to. I think it only happens 
> when people stop introspecting, and just blindly pull a bug off the top of 
> the list and proceed with "fixing" it.

Precisely.

When you have a bug, you need to understand what is causing
it.  That should be obvious.  What is not obvious to many
except those involved, is that often it is possible
to fix a bug without having fully figured out what's causing it.

Now sometimes it is ok.  E.g. if you haven't figured out
exactly what's causing it, but you know the module it's
happening in, and you figure you can just rewrite the
module and make it bug-proof.  In that case, you don't
have to know the path in the old module that caused
the bug to surface.

Other times are when the bug is very intermittent
and cannot be duplicated and you have to proceed
blindly, based on theories that are sometimes half-baked.

And then there are cases where you are working
with a crucial part of the system, without fully
understanding its full impact on the rest of the
system.  So you fix a bug, and the rest of the
system comes crashing down on you...

But the truth is the choice of language has little to
do with situations like these.  You just need professionalism
and discipline.  Don't fix until you are sure you
have found the bug, or at least the module where
the bug is.  If you have to shoot-in-the-dark,
use a source code control system so you can back
out of any theories that didn't work out, without
leaving new bugs.  If you are working with critical parts
of the system, read the code until you know what every
if statement does, and don't touch it until
you know EXACTLY what you are doing.  Don't
be afraid of re-writing large chunks of
the code, but only if you have done the
homework of understanding the old code cold.
None of which has to do with the language choice.

Sorry, there is NO magic bullet for such things.
I strongly doubt stories where the choice
of a new language turned all coders into
highly disciplined professionals, just like
I doubt array-bounds-checking is the most
useful invention in programming languages ever,
before which everybody was just sloppily writing
outside their arrays all the time as a matter of habit.