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: 103376,583275b6950bf4e6 X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,899fc98b2883af4a X-Google-Attributes: gidf43e6,public X-Google-Thread: fdb77,5f529c91be2ac930 X-Google-Attributes: gidfdb77,public X-Google-Thread: 1108a1,59ec73856b699922 X-Google-Attributes: gid1108a1,public X-Google-ArrivalTime: 2003-05-15 12:51:03 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news.ems.psu.edu!news.aset.psu.edu!not-for-mail From: Robert Spooner 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)) Date: Thu, 15 May 2003 15:48:15 -0400 Organization: Penn State University, Center for Academic Computing Message-ID: <3EC3EEFF.4030601@psu.edu> 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> <3EC3D737.6020509@attbi.com> NNTP-Posting-Host: nat4.arl.psu.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: f04n12.cac.psu.edu 1053028095 22120 128.118.40.103 (15 May 2003 19:48:15 GMT) X-Complaints-To: usenet@f04n12.cac.psu.edu NNTP-Posting-Date: Thu, 15 May 2003 19:48:15 +0000 (UTC) To: "Robert I. Eachus" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en,de,fr-FR Xref: archiver1.google.com comp.lang.java.advocacy:63864 comp.object:63486 comp.lang.ada:37366 comp.software-eng:19214 Date: 2003-05-15T15:48:15-04:00 List-Id: 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. 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 saw a hardware situation analogous to this when I worked in industry. The digital circuitry was on ten inch square wire wrap boards in rack cabinets. The circuitry was designed, then sent out to a wire wrap house to be semi automatically wrapped. Fully automatic wrapping was not feasible because the Manhattan pattern of the wires would make the circuitry too slow. Once a board returned and was populated, it would be tested. There were some design errors and some wire wrap errors because of chains being broken or tied together, etc. In looking at the defects over time, I saw an exponential decay curve. A technician would take one of these 10,000 pin boards, and have to add and remove wires. In the process, some mistakes would be made, perhaps miscounting pins, perhaps having to remove and then forgetting to replace some wires to get to a lower level error. Occasionally there were other design errors uncovered as well. After testing more changes would have to be done giving rise to a percentage of errors again. Assuming that the defect decay rate was a function of board size, it was easy to see that we would have been in real trouble if the boards had been 12 inches square instead of 10! The experience drove home to me the truth that you can't just scale up what works on a small project and expect it to work just as well on a large one. That's why Ada is so useful for programming in the large - it gives you the architectural tools you need so that you don't have to contend with the software version of a wire wrap board with 14,400 pins. The nuclear industry found out that scaling up a 50 megawatt submarine propulsion reactor to 500 or 1000 megawatts for power generation didn't work so well either. Bob -- Robert L. Spooner Registered Professional Engineer Associate Research Engineer Intelligent Control Systems Department Applied Research Laboratory Phone: (814) 863-4120 The Pennsylvania State University FAX: (814) 863-7841 P. O. Box 30 State College, PA 16804-0030 rls19@psu.edu