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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,fb1663c3ca80b502 X-Google-Attributes: gid103376,public From: Simon Brady Subject: Re: Writing better software was: Design by Contract (was Re: Interesting thread in comp.lang.eiffel) Date: 2000/08/01 Message-ID: <3985F031.B4862B40@below.for.email.address>#1/1 X-Deja-AN: 652973321 Cache-Post-Path: the-rowan.albatross.co.nz!sbrady@kakapo.otago.ac.nz Content-Transfer-Encoding: 7bit References: <8ipvnj$inc$1@wanadoo.fr> <39654639.B3760EF2@eiffel.com> <3984AD1D.830B538@below.for.email.address> <3984DC2D.C707824@swbell.net> X-Original-NNTP-Posting-Host: ns.albatross.co.nz X-Accept-Language: en Content-Type: text/plain; charset=us-ascii X-Abuse-Info: Otherwise we will be unable to process your complaint properly X-Complaints-To: abuse@GigaNews.Com X-Trace: sv2-yhFZH37ngKskgtQH14BnV3qK/sZRDHox++eASxDgtdhWyMXe3IQ3rG+2gtn3QR7IWK2+xXL8hT7sqDs!Z1oK9hNtVmRg5YbaUhgVaFL4 Organization: University of Otago CS Dept X-Original-Trace: 1 Aug 2000 09:31:30 +1200, ns.albatross.co.nz X-Cache: nntpcache 2.3.3 (see http://www.nntpcache.org/) MIME-Version: 1.0 NNTP-Posting-Date: Mon, 31 Jul 2000 17:06:14 CDT Newsgroups: comp.lang.ada Date: 2000-08-01T00:00:00+00:00 List-Id: John Magness wrote: > > In 1992 I took an Ada language course from an adjunct professor who was an > IBM employee. > He was a member of the shuttle flight software development team. He told > the class that NASA had asked IBM to determine the cost of the delivered > code. The result of the study was $5000.00 per line of delivered code. > That's late '80's dollars I think. What could NASA do to reduce this cost? It seems to me they have three options: 1. Accept (potentially) lower-quality software and fly with increased risk. 2. Accept lower-quality software but make system-wide adjustments so overall risk isn't reduced (e.g. put in more non-software backup) 3. Find a way to produce software of the same quality while using a cheaper process (1) is probably the easiest route to take, since risk is hard to quantify (until it bites you) and "acceptable" risk is a function of all sorts of malleable social and politcal factors. Of course we have to ask "acceptable to whom?", and the tradeoffs don't seem at all obvious: how does one determine the ultimate cost (to national morale, support for the space program and related industries, etc.) of losing a Shuttle? Speaking as a software geek, (2) feels like a step backward, yet it still seems to be an embarressingly appropriate option for many systems (remember Therac-25). But is it really practical for something as complex as the Shuttle? Or have we reached a "damned if we do, damned if we don't" point where we have no choice but to rely on software, creaky as it may be? (3) is, IMO, the holy grail of software engineering. If anyone has realistic suggestions of how it could be done (for the Shuttle or any similar CMM-5 shop), I for one would be interested to hear them. Simon Brady sjbrady Research Assistant, Computer Science Dept. at University of Otago, Dunedin, New Zealand acm dot org