Re: [Lit.] Buffer overruns
From: Douglas A. Gwyn (DAGwyn_at_null.net)
Date: 12/24/04
- Next message: Douglas A. Gwyn: "Re: [Lit.] Buffer overruns"
- Previous message: Les Ritchin: "Re: Enigma Cipher Definition"
- In reply to: Bryan Olson: "Re: [Lit.] Buffer overruns"
- Next in thread: Mok-Kong Shen: "Re: [Lit.] Buffer overruns"
- Reply: Mok-Kong Shen: "Re: [Lit.] Buffer overruns"
- Reply: Bryan Olson: "Re: [Lit.] Buffer overruns"
- Reply: Mok-Kong Shen: "Re: [Lit.] Buffer overruns"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Fri, 24 Dec 2004 00:58:27 -0600
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. It is well known that everything NASA
does (or more accurately, administers) costs several
times what it would cost private industry, but the
quality is not several times higher, alas. My experience
is that a well-led small team of well-trained engineers
can in a couple of years produce from scratch a huge
system, in C, that is well specified, well designed,
well produced, well tested, well documented, and easy to
maintain. Of course, once one has such an ongoing
operation, it is no longer necessary to start from
scratch for each new project, so it becomes more
economical with time. The cost (including overhead) is
something like $300/line, but the product is much more
than mere lines of code. There would be a comparable
cost for doing a similar job in any major PL, and it
could even be more if the PL weren't very flexible (so
that much of the effort is spent on overcoming its
inadequacies). The key is in assembling the right
team and then supporting them.
> The C apologists are so mired in their antiquated thinking that
> they can't even see the value of the newer tools. They don't
> really even disagree with the research on software reliability;
> they're simply oblivious to it. They want people to trust them
> for their experience, even though they know full well that their
> experience is in producing software that's either unaffordable
> or buggy.
You are so mired in your erroneous viewpoint that you
don't bother to understand what others are saying.
I assume you're referring primarily to me, and though
I don't think I should have to defend myself against
such allegations, it is a point of fact that I have
been involved in software reliability engineering for
a very long time (I even used to review books and
articles on the subject for Computing Reviews), and a
great many computer systems you are likely to use
incorporate software that I produced, largely in C,
which has been quite affordable and reliable. The
core operations of several organizations have been
dependent on the reliability of large software systems
for which I was principal architect and developer,
much of it in C; thus I have much directly relevant
experience which you would do better to learn from
rather than argue with.
- Next message: Douglas A. Gwyn: "Re: [Lit.] Buffer overruns"
- Previous message: Les Ritchin: "Re: Enigma Cipher Definition"
- In reply to: Bryan Olson: "Re: [Lit.] Buffer overruns"
- Next in thread: Mok-Kong Shen: "Re: [Lit.] Buffer overruns"
- Reply: Mok-Kong Shen: "Re: [Lit.] Buffer overruns"
- Reply: Bryan Olson: "Re: [Lit.] Buffer overruns"
- Reply: Mok-Kong Shen: "Re: [Lit.] Buffer overruns"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
