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

["Robert I. Eachus" <rieachus@attbi.com>]

Preben Randhol wrote:

> A great many things are possible, yet not practical. (Isaac Asimov)
> Or in other words you can probably make a huge complex system in
> assembly code, but it will take you a couple of decades to get the job
> done.

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.  But it also allows you to determine 
when, and in fact if, a new development project is ever going to be 
complete.

Obviously, if each bug fix (on average) creates one new bug, you can 
never win.  The problem is that a bug tracking system only contains bugs 
that have been found, whether or not they have been fixed.  So from 
experience when the observed ratio reaches 0.3 on a new development 
project you are probably already slipping schedule, hit 0.4 and you are 
in deep kimchee.  For fielded software that is being actively 
maintained, at about 0.6 it is time to start working on the complete 
rewrite.  Of course, the reality is that if you are smart you rewrite 
individual modules where the rate of secondary bugs is high and keep the 
overall system working until it is replaced or retired.

I've never written the tool, because my role at MITRE meant that I 
usually only had access to the contractors bug database, and if I was 
lucky, the source code.  But going through the database and classifying 
bugs as original or secondary was usually sufficient to tell me how bad 
off the project was.  The largest amount of documentation associated 
with a single bug is probably a good proxy.  Above 10 pages or so, you 
are entering the twilight zone.  I remember one bug report that included 
134 separate code changes in the fix.  Is it any wonder that that 
project never had working software and was eventually cancelled?)

I don't think I have ever worked on an Ada project where this ratio ever 
got high enough to be statistically greater than zero.  (Yes, if you 
have one such incident you know the ratio is greater than zero.  But the 
standard error, as calculated, included zero.)  At Verdix (now part of 
Rational, now part of IBM ;-) they tracked this type of information for 
their Ada compiler, originally written in C.  When the number of bugs 
associated with a given module was too high, they rewrote the module in 
Ada.  Even with the fact that this meant that only the more complex 
parts of their compiler were eventually written in Ada, the bug rate for 
the Ada sections was much lower.  (You could argue that this biased 
their data because the Ada modules were second attempts, but there were 
also some parts of the compiler that were never written in C.)