Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!linus!decvax!ucbvax!ucdavis!lll-crg!gymble!umcp-cs!seismo!brl-tgr!tgr!glenn@LL-XN.ARPA
From: glenn@LL-XN.ARPA (Glenn Adams)
Newsgroups: net.unix-wizards
Subject: Re:  code quality
Message-ID: <2040@brl-tgr.ARPA>
Date: Thu, 10-Oct-85 10:22:27 EDT
Article-I.D.: brl-tgr.2040
Posted: Thu Oct 10 10:22:27 1985
Date-Received: Sat, 12-Oct-85 07:22:20 EDT
Sender: news@brl-tgr.ARPA
Lines: 38


I agree with you completely.  For specific situations such as the one you
pointed out, there is obviously little excuse.  Especially so since the
use of lint would actually have identified most of these problems.  What
we are really talking about here is the REAL need for Software Quality
Control and Assurance.  However, without some well defined methodology for
attempting quality judgement it is quite difficult to qualify and impossible
to quantify by any reasonable metric how a particular piece of code measures
up against some ill-articulated standard.  An even greater problem is that
true quality must begin with a commitment by management to encourage and
demand such control.  This is where, at least in the past, that I believe
has been the greatest weakness.

As far as UNIX and C are concerned, I don't think any greater crimes have
been committed in this domain of software than any others.  It may have been
more prudent to invoke lint as an option for 'cc' than make it an independent
utility; however, I think it is the integrity of the individual programmer
that must prevail.  Careful programmers are often condemned by their own
management for spending too much time smoothing off the rough edges and running
up their software development costs.  On the other hand, when careless ones
are employed, they may keep the initial development costs low by cutting all
corners, but result in extremely high maintenance costs once the system is
deployed.  I think that this problem is not unique to software but is present
in all fields from home-building to the construction of nuclear reactors.

This problem is far from being solved and much discussion and thought is still
required.  What we are talking about here is the real practice, or praxis, of
Software Engineering as a professional technique.  The Greeks had a word for
this which we see quite often these days, he texne, which means the practice of
an art in a professional sense:  a real skill.   Prof. Knuth chose this word as
the namesake of TeX, and I think he chose it because it signified that
typesetting was an art, yet it required a very professional skill or technique
to accomplish a significant work.  I would like to see the creation of all
software viewed in a similar fashion.

Maybe we should continue this discussion in Soft-Eng@MIT-XX.ARPA.

Glenn Adams