Re: [Lit.] Buffer overruns

From: Bryan Olson (fakeaddress_at_nowhere.org)
Date: 12/24/04


Date: Fri, 24 Dec 2004 12:21:35 GMT

Douglas A. Gwyn wrote:
> Bryan Olson wrote:
>
>> In some areas, we do spend the money. The Space Shuttle On-board
>> Software development group has a world-renowned engineering
>> process. They produce reliable, validated software, for about
>> $20,000 per line. The software controlling commercial passenger
>> jets is also highly reliable and reportedly costs less: just
>> $15,000 a line.

> That's not a good metric, but even so it needn't cost
> nearly so much.

I'm not talking about how much I think it should cost; I'm
noting how much it actually does cost. (I heard the figures
from Gary McGraw.) You cannot refute fact with opinion or
personal anecdote.

[...]
> My experience
> is that a well-led small team of well-trained engineers [...]
[...]
> it is a point of fact that I have
> been involved in software reliability engineering
[...]
> thus I have much directly relevant
> experience which you would do better to learn from
> rather than argue with.

In case you haven't noticed, I show no respect for arguments
from self-proclaimed authority. Real experts have more to say
than "because I say so". Look to Wagner's posts on Cryptology;
they're not about how we should believe him because he's a noted
cryptologist. He cites the results.

Contrary to indications in this thread, there's been a lot of
research on software reliability in the past few decades. I've
been trying to support my positions with facts and results. The
paragraph of my previous post about the DOD's "software crisis"
-- that's not just my own take; anyone can Google it. I cited a
study comparing development in Ada versus C, and concluding Ada
was better for productivity and reliability. Is that one study
conclusive? Well no, but what can people cite on the other
side?

Of course I do have an opinion. There are situations that call
for C or assembly; I've heard no one here claim otherwise. Those
languages have a significant disadvantage in safety and
security: for any plausible budget, programmers can produce a
more reliable system in newer, safer languages. The sensible
thing to do is use C/C++ and assembly for the small portion of
code where their low-level features really matter, and safer
languages for the rest. Let risk levels guide the spending of
the verification and validation budget, which implies devoting
more resources per function-point to C code than code in safer
languages.

Mr. Gwyn you may well have been programming since before I was
born. If you continue to use that as justification for your
positions, I will continue to show that attitude the disrespect
it deserves.

-- 
--Bryan


Relevant Pages

  • Re: Metrics on stack usage
    ... and exploiting knowledge that the Algol ... Do you know of any papers on code reliability in Forth applications given ... series terms in the system reliably are larger than say algol languages) ... I don't understand what "don't have a formal interface" means. ...
    (comp.lang.forth)
  • Re: Forth and Co - The Return of the Jedi
    ... But if Forth is a way of devising languages, then this sort of stability indicates that Standard Forth isn't Forth at all: it's a merely a stagnant language frozen in an immature state. ... Maybe you should consider Fortran for your next high reliability project. ... Were vacuum tube computers more reliable than transistor computers? ...
    (comp.lang.forth)
  • Re: language predication
    ... the dominant languages. ... Okay, "evidentials" indicate... ... reliability, ... djheydt at gmail dot com ...
    (rec.arts.sf.composition)
  • Re: Differences between C and C++
    ... qualifiers needed to make my statements accurate. ... reliability SW ... comparison with the similarities. ... are two different but similar languages you should have few problems. ...
    (comp.lang.c)