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: 103376,583275b6950bf4e6 X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,899fc98b2883af4a X-Google-Attributes: gidf43e6,public X-Google-Thread: 1108a1,59ec73856b699922 X-Google-Attributes: gid1108a1,public X-Google-ArrivalTime: 2003-05-16 08:40:55 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!arclight.uoregon.edu!wn13feed!worldnet.att.net!204.127.198.203!attbi_feed3!attbi.com!rwcrnsc54.POSTED!not-for-mail Message-ID: <3EC50672.2010405@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> <3EC3D737.6020509@attbi.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: rwcrnsc54 1053099654 24.62.164.137 (Fri, 16 May 2003 15:40:54 GMT) NNTP-Posting-Date: Fri, 16 May 2003 15:40:54 GMT Organization: AT&T Broadband Date: Fri, 16 May 2003 15:40:54 GMT Xref: archiver1.google.com comp.lang.java.advocacy:63923 comp.object:63551 comp.lang.ada:37394 comp.software-eng:19235 Date: 2003-05-16T15:40:54+00:00 List-Id: Shayne Wissler wrote (I'm quoting it in full because it deserves to be reread): > 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. > > A methodical approach can appear to be less efficient, and I'm sure it's the > pressure to deliver that leads to many breaches in integrity to a proper > engineering methodology. Of course, in the long run, such breaches always > end up costing you more. > > A lot of software does deserve to be completely rewritten. But that should > be apparent by how slow you have to go when adding features, not by > ever-cascading bugs. On the contrary, if you see bugs spiraling out of > control, that's evidence that you don't want that particular team and/or > its management to undertake rewriting the system. Everything you say is true, and good advice. But you need to know where I am coming from. At MITRE software engineers are often used by the government as firemen to go into an out-of-control project and determine what can be done to fix things. Sometimes the advice has to be that the project is hopeless and can't be saved. If the software is too brittle, it doesn't matter how it got that way, all that matters is that the only way to ever deliver a product is to fund a new project with a new team, and bury the original code so that it can't possibly be reused. Expensive? Not really. It is like a fireman deciding that they can save all the buildings around the one that is burning, or try to save that building and lose everything. It is not a decision you take lightly. Let me give two examples. The first is one where MITRE was involved, called Cheyanne Mountain Upgrade. At the time it was started, the Soviet Union was still a threat, and NORAD being off the air for even part of a day was considered unacceptable. The overall project was a success, even though the reasons for that success involved spending extra money to put firewalls between each component of the upgrade. Some of the components were late and involved lots of nasty problems like changes in requirements. (It doesn't matter if the system can deal with the original threat assessment. If the threat changes, the real requirements must change. Also one of the biggest requirements changes was caused by the Goldwater-Nichols reorganization of the DoD command structure.) But because of the firewalling each component was of managable size and could be installed without depending on other parts of CMU. The other example is a program where MITRE was not the FFRDC invovled. The A-12 attack aircraft program for the Navy did not have this type of firewalling. By the time that budget overruns and schedule delays brought the program to the attention of Congress, the whole project was unsalvageable. (And, yes, some of the people who let it get out of control were fired. See http://www.fas.org/man/dod-101/sys/ac/a-12.htm for a write up of the disaster.) In any case, my reasons for wanting to develop a defect management tool was not for the people actually involved in the project. It was so that the government and FFRDC people involved in managing the project for the government could detect the problem before it was too late. The most important thing to take away from this discussion is that it is possible to get to the point where it really is too late to save the project.