Re: Writing better software was: Design by Contract (was Re: Interesting thread in comp.lang.eiffel)

[xanthian@well.com (Kent Paul Dolan)]

Ken Garlington <Ken.Garlington@computer.org> wrote:
>"Kent Paul Dolan" <xanthian@well.com> 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.