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: 1108a1,59ec73856b699922 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,899fc98b2883af4a X-Google-Attributes: gidf43e6,public X-Google-Thread: 103376,583275b6950bf4e6 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-05-17 08:28:44 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!uio.no!uninett.no!news.net.uni-c.dk!sunsite.dk!newsfeed1.uni2.dk!newsfeed101.telia.com!nf01.dk.telia.net!news104.dk.telia.net!not-for-mail Message-ID: <3EC65525.186A7BB7@mail1.stofanet.dk> Date: Sat, 17 May 2003 15:28:37 +0000 From: Bjorn Reese Organization: Hyperspace Academy X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.7 i686) X-Accept-Language: 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 Content-Transfer-Encoding: 7bit NNTP-Posting-Host: 212.10.34.229 X-Trace: 1053185323 news.stofanet.dk 4384 212.10.34.229 X-Complaints-To: Telia Stofa Abuse Xref: archiver1.google.com comp.lang.java.advocacy:64015 comp.object:63611 comp.lang.ada:37449 comp.software-eng:19259 Date: 2003-05-17T15:28:37+00:00 List-Id: Shayne Wissler wrote: > 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. [...] > 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. While sloppiness, or similar human traits, may be a contributing factor, I think that it is too simplistic to attribute cascading defects to this single factor. Nor do I believe that the situation will improve in general by replacing the people. The major factor, in my experience, to cascading defects is increasing cognitive complexity of the system, usually combined with insufficient staffing. The problem is that no matter how clever your staff is, they will eventually reach a break-even point where the cognitive complexity of the system exceeds their mental capabilies. Blaming or replacing the staff will not decrease cognitive complexity. If you replace the staff, you also risk that the new people will simply make the same mistakes that the old staff did. Assuming that at least some from the old staff is capable of learning from their errors, they may be in a better position to rewrite the system. They also have a broader understanding of the required domain knowledge.