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,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1108a1,59ec73856b699922 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,583275b6950bf4e6 X-Google-Attributes: gid103376,public X-Google-Thread: fdb77,5f529c91be2ac930 X-Google-Attributes: gidfdb77,public X-Google-Thread: f43e6,899fc98b2883af4a X-Google-Attributes: gidf43e6,public X-Google-ArrivalTime: 2003-05-16 10:24:37 PST Path: archiver1.google.com!postnews1.google.com!not-for-mail From: softeng3456@netscape.net (soft-eng) 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: 16 May 2003 10:24:36 -0700 Organization: http://groups.google.com/ Message-ID: <9fa75d42.0305160924.2bf76373@posting.google.com> References: <9fa75d42.0304230424.10612b1a@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: 32.97.239.19 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1053105877 27102 127.0.0.1 (16 May 2003 17:24:37 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: 16 May 2003 17:24:37 GMT Xref: archiver1.google.com comp.lang.java.advocacy:63932 comp.object:63553 comp.lang.ada:37396 comp.software-eng:19237 Date: 2003-05-16T17:24:37+00:00 List-Id: Shayne Wissler wrote in message news:... > 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. > > 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. Precisely. When you have a bug, you need to understand what is causing it. That should be obvious. What is not obvious to many except those involved, is that often it is possible to fix a bug without having fully figured out what's causing it. Now sometimes it is ok. E.g. if you haven't figured out exactly what's causing it, but you know the module it's happening in, and you figure you can just rewrite the module and make it bug-proof. In that case, you don't have to know the path in the old module that caused the bug to surface. Other times are when the bug is very intermittent and cannot be duplicated and you have to proceed blindly, based on theories that are sometimes half-baked. And then there are cases where you are working with a crucial part of the system, without fully understanding its full impact on the rest of the system. So you fix a bug, and the rest of the system comes crashing down on you... But the truth is the choice of language has little to do with situations like these. You just need professionalism and discipline. Don't fix until you are sure you have found the bug, or at least the module where the bug is. If you have to shoot-in-the-dark, use a source code control system so you can back out of any theories that didn't work out, without leaving new bugs. If you are working with critical parts of the system, read the code until you know what every if statement does, and don't touch it until you know EXACTLY what you are doing. Don't be afraid of re-writing large chunks of the code, but only if you have done the homework of understanding the old code cold. None of which has to do with the language choice. Sorry, there is NO magic bullet for such things. I strongly doubt stories where the choice of a new language turned all coders into highly disciplined professionals, just like I doubt array-bounds-checking is the most useful invention in programming languages ever, before which everybody was just sloppily writing outside their arrays all the time as a matter of habit.