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

["Ken Garlington" <Ken.Garlington@computer.org>]

"Kent Paul Dolan" <xanthian@well.com> wrote in message
news:hwoh5.3977$ED.168424@news.wenet.net...
> 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.

There's two bad assumptions here:

(1) "Software folk wisdom" is better than data from controlled case studies.
This is CMM level 2 thinking at best.

(2) Considering languages issues and "process issues" is mutually exclusive.
Not true - you can (and should) consider all sources of error in an
effective software quality program. (For example, although Brooks discusses
a number of process issues, he also notes that "programming productivity may
be increased as much as five times when a suitable high-level language is
used.")


> 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.

Certainly, there may be formal computer science programs that don't offer
software engineering courses. However, I'd guess that most programs today do
not consider these as mutually exclusive. I've taken a number of courses in
both management sciences and software engineering. Although there's some
overlap (as there is with many other engineering fields, such as petroleum
engineering and chemical engineering), I don't think you could honestly
consider it as just as "specialization" of management science.

> 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.

However, there are groups that get the same results as the space shuttle
program at significantly less cost. Again, when you look at the case studies
vs. "folk wisdom," the results may be surprising.

> 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.

Interestingly, Brooks withdrew this advice in the 1995 edition of Mythical
Man-Month, as it tends to assume the waterfall model. He suggests in his
revised book that an incremental-build model is better. In fact, one of the
specific models he describes is the Microsoft "build every night" approach!

> 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.

However, CMM level 4 companies are finding that they (a) can control
variation in the software development process, putting the lie to the
"100:1" variation that was seen when there was no attempt to control the
process and (b) can use things such as formal inspections to significantly
reduce error rates earlier in the process than traditional testing.