Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!think!husc6!talcott!necntc!mirror!cca!g-rh
From: g-rh@cca.UUCP (Richard Harter)
Newsgroups: net.cse
Subject: Re: quality software
Message-ID: <10568@cca.UUCP>
Date: Fri, 17-Oct-86 02:22:19 EDT
Article-I.D.: cca.10568
Posted: Fri Oct 17 02:22:19 1986
Date-Received: Tue, 21-Oct-86 07:40:37 EDT
References: <10410@cca.UUCP> <10528@cca.UUCP>
Reply-To: g-rh@cca.UUCP (Richard Harter)
Organization: Computer Corp. of America, Cambridge
Lines: 63
Summary: Chris Torek is a very sensible fellow.

chris@umcp-cs.UUCP (Chris Torek) writes:

RH: (b)	Pursuant to (a) the software must be substantially and
RH: 	correctly documented from the prospective user's viewpoint.

CT: Having written and distributed a few programs myself, I have come
CT: to the tenative conclusion that the documentation is actually
CT: MORE important than the code itself!  If the code is buggy, a few
CT: people will have trouble.  If the documentation is buggy, many will
CT: have trouble.

	Listen to this man!  Forsooth, I say unto you, he has the
	truth of it.  


CT: As for code
CT: correctness, the consistent lack thereof is one reason we insist
CT: on source.  We (UMCP Computer Science Department) are not willing
CT: to wait for a company to fix bugs.  Student labour is cheap:  we
CT: will fix it ourselves.  As a bonus, we will send back a bug report
CT: *with a fix*.  (So why is it so hard to get sources for c-ware?)

Pragmatically, two reasons.  The first is that it is much harder
to support and maintain software when users can get their sticky
little fingers in it.  (If I sell you a program and you modify it
and then later report a bug and I am supporting the program, then I
am caught in the trap of possibly having to fix your bugs.)  The
other is a matter of protection -- source code is a valuable property.

	[Many intelligent observations deleted.]

RH: 	Nonetheless there are substantive differences between
RH: software production in an academic setting and in "industry" as
RH: I hope I have made clear.  And I will say, dogmatically, that it
RH: rests on academia to understand what those differences are and
RH: to teach something about the nature of producing production quality
RH: software.
CT: 
CT: Students learn by doing; that is why we have all these silly
CT: projects.  Producing quality software requires certain skills,
CT: including algorithm design, coding, and natural language: English,
CT: at least here and across the pond.  These we (academia) can teach.
CT: Nevertheless, quality software, if it is to be nontrivial, requires
CT: one thing we can not supply.  It requires time.
CT: 
CT: I respectfully submit that we can teach only the elements, and that
CT: it is up to the students to put them together out in the `real
CT: world'.

	Chris makes a very good point here.  Experience must be paid
for and the price is time.  There is, however, a world of difference
between experience grounded in original ignorance and experience
grounded in a broad spectrum of skills.  However I will stand with
what I said.  I didn't mean that academia must teach by "learn by
doing" -- as Chris points out, there simply isn't the time for it.
It is not the "doing" that I was asking for, but that students learn
that there is "doing" to be done, and something about what that "doing"
is.

-- 

Richard Harter, SMDS Inc. [Disclaimers not permitted by company policy.]
	For Cheryl :-)