Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!caip!rutgers!husc6!seismo!umcp-cs!chris From: chris@umcp-cs.UUCP (Chris Torek) Newsgroups: net.cse Subject: Re: quality software Message-ID: <3877@umcp-cs.UUCP> Date: Wed, 15-Oct-86 10:22:34 EDT Article-I.D.: umcp-cs.3877 Posted: Wed Oct 15 10:22:34 1986 Date-Received: Tue, 21-Oct-86 00:04:25 EDT References: <10410@cca.UUCP> <10528@cca.UUCP> Organization: Computer Sci. Dept, U of Maryland, College Park, MD Lines: 94 (There really IS something relating to C.S. education, down near the end. The point-by-point replies can be summarised as `in my experience, companies and universities have equal records regarding software quality'.) In article <10528@cca.UUCP> g-rh@cca.UUCP (Richard Harter) writes: >... Significant features of production quality software include: > >(a) The software will run by a number of people (customers) who > have paid hard cash for the software. ... It should be (but, I admit, often is not) considered irrelevant what someone has paid. >(b) Pursuant to (a) the software must be substantially and > correctly documented from the prospective user's viewpoint. Having written and distributed a few programs myself, I have come to the tenative conclusion that the documentation is actually MORE important than the code itself! If the code is buggy, a few people will have trouble. If the documentation is buggy, many will have trouble. A lack of documentation is always a mark of `universityware', though the converse is not true. A company cannot get away with selling undocumented software, while a university can easily give away the same. Yet my own limited observation tells me that the accuracy of the documentation (when present) is equally good---or bad---in `universityware' and `companyware'. [From here on, I will use the abbreviations `u-ware' and `c-ware'.] >(c) The software should be substantially error free (ideally > it should be completely error free -- however.) It should > work not only when used by the creator, but also when used > by the end users. In particular there should be no "don't > do that because we didn't take care of that case" loose > ends. Loose ends seem to appear with equal frequency in both u- and c-ware, but those in c-ware are not documented. As for code correctness, the consistent lack thereof is one reason we insist on source. We (UMCP Computer Science Department) are not willing to wait for a company to fix bugs. Student labour is cheap: we will fix it ourselves. As a bonus, we will send back a bug report *with a fix*. (So why is it so hard to get sources for c-ware?) >(d) The software should be rigorously tested. It is not enough > that it works in the small number of situations of immediate > interest to the creator. It must work under a wide variety > of situations. Testing and validation is a major part of > the work in preparing production software (or ought to be.) This is the whole point of beta testing. Why, then, do Certain Unnamed Companies ignore the bug reports from their beta test sites? [more points, up to (i), that I will leave unanswered] > I could go on. Perhaps I should make the caveat that >much software that is commercially available is not of production >quality by the standards I have listed :-). ... Indeed. > Now let us consider a typical program in an academic >setting. [That is, if there is such an animal -- BSD4.x and >the beginning student's first program don't have much in common.] It is nice to know that someone else also thinks so! :-) [More points unanswered: for small projects, much of the work that goes into quality software---I will not say `production quality', for quality stands alone---is not warranted. Agreed.] > Nonetheless there are substantive differences between >software production in an academic setting and in "industry" as >I hope I have made clear. And I will say, dogmatically, that it >rests on academia to understand what those differences are and >to teach something about the nature of producing production quality >software. Students learn by doing; that is why we have all these silly projects. Producing quality software requires certain skills, including algorithm design, coding, and natural language: English, at least here and across the pond. These we (academia) can teach. Nevertheless, quality software, if it is to be nontrivial, requires one thing we can not supply. It requires time. I respectfully submit that we can teach only the elements, and that it is up to the students to put them together out in the `real world'. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu