Account Options

  1. Sign in
The old Google Groups will be going away soon.
Switch to the new Google Groups.
Google Groups Home
« Groups Home
comp.lang.java.advocacy
+ new post
About this group
Subscribe to this group
This is a Usenet group - learn more
Message from discussion Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Robert I. Eachus  
View profile  
 More options May 15 2003, 2:07 pm
Newsgroups: comp.lang.java.advocacy, comp.object, comp.lang.ada, comp.software-eng
From: "Robert I. Eachus" <rieac...@attbi.com>
Date: Thu, 15 May 2003 18:07:04 GMT
Local: Thurs, May 15 2003 2:07 pm
Subject: Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died))
Print | View thread | Show original | Report this message | Find messages by this author

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.)


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2012 Google