Xref: utzoo comp.sw.components:320 comp.software-eng:2138
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!ico!vail!rcd
From: rcd@ico.ISC.COM (Dick Dunn)
Newsgroups: comp.sw.components,comp.software-eng
Subject: Re: Schedule and budget are secondary
Summary: We need answers...not platitudes, nor insults
Message-ID: <16193@vail.ICO.ISC.COM>
Date: 12 Oct 89 03:54:08 GMT
References: <16187@vail.ICO.ISC.COM> <6742@hubcap.clemson.edu>
Organization: Interactive Systems Corp, Boulder, CO
Lines: 82

I was gritching about quality being given short shrift, and had pointed out
that software can be constructed which meets all objective requirements,
yet is of poor quality.

>     This depends upon whether the product is implemented by hackers
>     or by professionals...

Hey, groovy...we'll just get our customers to add a clause to the contract
to require that "All software shall be implemented by professionals.
Hackers shall not be employed..." and nobody will have to worry about poor
quality software any more, right?

Of course good people will produce better software than bad people.  That
is true, but irrelevant to the point I was trying to make--which is that
the relative emphasis on quality will influence the result.  A good
programmer, under extreme time/budget pressure, will likely be able to
produce better-quality software than a dullard working at leisure who
codes with a chainsaw .  But the professional won't do as good a job as if
there were more external interest in quality and less extreme time/money
pressure.

>...A professional will meet cost and schedule
>     constraints by using CASE tools, advanced programming languages,
>     and so on...

No.  A professional will use the tools suitable for the job (perhaps
creating them if appropriate).  A professional will focus on the job of
constructing good software, and will leave the buzzword-oriented
programming to the acolytes of strongly-hyped languages.  (apologies to
Andrew Koenig)

And what's this about advanced programming languages?  Wolfe has, in other
postings, been an outspoken advocate of Ada, which is certainly *not*
advanced.  In fact, the difficulty of making Ada catch up to current
technology has been a hot topic over in comp.lang.ada.

>     Dick's particular environment is one in which operating system 
>     software is being developed in C, a double whammy as far as a 
>     well-established tradition of hacking is concerned...

There is operating system software developed in C at Interactive Systems.
That's not what I'm doing, although that is irrelevant.  C is well suited
to the task.  (Most of the OS work is, for example, better done in C than
in C++.  But you have to understand what "most of the work" is about, and
that's another topic.)

The "well-established tradition of hacking" is an empty insult, a manifes-
tation of Wolfe's inability to mount any substantive objection.  C works. 
UNIX works.  They've lasted well, and survived incredible amounts of modifi-
cation and adaptation.  All the cheap insults you can dream up won't change
that.  We'll trade taunts with you for a while; then we'll let you go back
to *talking* about software while we *produce* software.

Don't get me wrong--C is *not* The One True Way.  (That's religion, which
is anathema:-)  C is *a* way to get things done, and done both well and
expeditiously.  There are other languages and tools--some of them more
appropriate to their problem domains than C could be.

>	In such an
>     environment, great efforts must be taken on the part of management
>     to ensure the existence of a proper software engineering orientation.

Not at all.  You just get good people who know what they're doing, and make
room for them to do their jobs.  Good management does not direct; it
assists.

The people I work with are not the people who produce the nasty code I was
complaining about in my earlier posting.  In fact, some of the nastiest
code was produced as a result of blind, dogmatic application of so-called
software engineering principles.  It's gotten them into binds.  We have to
help them out, help clean up the messes, and get the software headed back
in a reasonable direction.  We do it in C (since that's what all of them
are using), without dogma and buzzwords.  Sometimes we have to tell them
that getting back to quality software is going to cost a little more and
take a little longer than the "shortest path" to meeting the immediate
requirements.  When we can make a good case for it, they're likely to go
for it--because they've seen how we work and they appreciate the long-
term benefits.  We budget and plan for quality work; we don't "lowball"
contracts.
-- 
Dick Dunn     rcd@ico.isc.com    uucp: {ncar,nbires}!ico!rcd     (303)449-2870
   ...No DOS.  UNIX.