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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,e01bd86884246855 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,fb1663c3ca80b502 X-Google-Attributes: gid103376,public From: xanthian@well.com (Kent Paul Dolan) Subject: Re: Writing better software was: Design by Contract (was Re: Interesting thread in comp.lang.eiffel) Date: 2000/08/01 Message-ID: #1/1 X-Deja-AN: 653011705 References: <8ipvnj$inc$1@wanadoo.fr> <397D8CC3.BB0C9001@ix.netcom.com> X-Complaints-To: news@wenet.net X-Trace: news.wenet.net 965088397 208.178.101.2 (Mon, 31 Jul 2000 17:06:37 PDT) Organization: Birthright Party "The birthright of humankind is the stars!" X-Received-Date: Mon, 31 Jul 2000 17:07:06 PDT (newsfeed.avtel.net) Reply-To: xanthian@well.com (Kent Paul Dolan) NNTP-Posting-Date: Mon, 31 Jul 2000 17:06:37 PDT Newsgroups: comp.lang.ada,comp.lang.eiffel Date: 2000-08-01T00:00:00+00:00 List-Id: Ken Garlington wrote: >"Kent Paul Dolan" wrote: >> For those interested in how to write better software, the language is >> not the issue. >Certainly, language is not the *only* issue, but it can have an effect on >your defect rates. Software folk wisdom is that any programmer can write awful code in any language; I most recently found that reiterated by Bjarne Stroustrup in his special edition C++ textbook. I think neglecting language issues to focus on process issues is going to pay off faster than the opposite approach, and also that until you have some good process in place, the best programming language in the world (since this is crossposted, I won't mention her name right here) isn't going to offer much relief. >> Arguably the best software ever written was in some >> language "HAL" of which I never heard until reading the case study in >> CMU SEI's "The Capability Maturity Model". >Wasn't HAL invented by Intermetrics for the space program? Wouldn't surprise me, since the space program was the target application. >> The case study in the above book of necessity only follows the project >> studied up to the book's publication date. Later breaking news is the >> delivery of a suite of software for space shuttle control with one bug >> detected ever in the delivered product. Not "one bug per KLOC", >> _one_bug_. >Actually, that's typical for safety-critical software -- for example, I >don't think we've ever received a single defect report from the field for >the production F-16 or F-111 digital flight controls. >> They got to that point with management science, not computer science. >Actually, we (Lockheed Martin Aero) did a benchmarking visit with the space >shuttle control team last year. They will be the first to tell you that it's >both "management science" and "computer science" (not that those are >entirely disjoint terms). Happy to hear, since you bought the team from IBM, that you are taking the time to spread the benefits at least internally!! I'd rather think of it as a computer specialization of well known management science approaches. What I was taught in formal education as "computer science" had nothing to do with what these people used to achieve their astonishing software error rate. >However, they will also tell you that their dollars invested per SLOC is >much higher than the industry average (again, typical for safety-critical >software). It may be that using more "computer science" (e.g., using more >COTS) will permit lower costs while still retaining the kinds of defect >rates expected for this type of software. Yep, they spent about four times the industry average per SLOC for that software. From my point of view, that just means the industry _way_ underfunds software development, with the results we all know and detest. Software _looks_ so simple, and the estimates are _so_ optimistic, that the old well worn ideas: "you will always build a prototype, some groups just find that out later than others", paraphrasing Fred Brooks, get ignored in doing the up front cost estimates. This group as part of its mandatory, customer funded process, builds and throws away one complete prototype, just to assure that they know where the software problems are going to arise, _before_ starting coding, or finalizing architecture or design, on the deliverable software. It's when you find out that software productivity, between competent practitioners, can vary by 100::1, and that all the testing in the world lets buggy software out the door, that you begin to realize that software is not simple, not well understood, not well managed, and not well accomplished, with vanishingly few exceptions, the one under review being one of them. Cheers! xanthian.