From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fdb77,5f529c91be2ac930 X-Google-Attributes: gidfdb77,public X-Google-Thread: f43e6,899fc98b2883af4a X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,583275b6950bf4e6 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,59ec73856b699922 X-Google-Attributes: gid1108a1,public X-Google-ArrivalTime: 2003-05-15 11:07:05 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!arclight.uoregon.edu!wn13feed!wn12feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi_feed4!attbi.com!sccrnsc01.POSTED!not-for-mail Message-ID: <3EC3D737.6020509@attbi.com> From: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.java.advocacy,comp.object,comp.lang.ada,comp.software-eng Subject: Re: Quality systems (Was: Using Ada for device drivers? (Was: the Ada mandate, and why it collapsed and died)) References: <9fa75d42.0304230424.10612b1a@posting.google.com> <9fa75d42.0305090612.261d5a5c@posting.google.com> <9fa75d42.0305091549.48b9c5d9@posting.google.com> <7507f79d.0305121629.5b8b7369@posting.google.com> <9fa75d42.0305130543.60381450@posting.google.com> <254c16a.0305140549.3a87281b@posting.google.com> <9fa75d42.0305141747.5680c577@posting.google.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 24.62.164.137 X-Complaints-To: abuse@attbi.com X-Trace: sccrnsc01 1053022024 24.62.164.137 (Thu, 15 May 2003 18:07:04 GMT) NNTP-Posting-Date: Thu, 15 May 2003 18:07:04 GMT Organization: AT&T Broadband Date: Thu, 15 May 2003 18:07:04 GMT Xref: archiver1.google.com comp.lang.java.advocacy:63859 comp.object:63480 comp.lang.ada:37361 comp.software-eng:19211 Date: 2003-05-15T18:07:04+00:00 List-Id: 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.)