chris@umcp-cs.UUCP (Chris Torek) (10/15/86)
(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
eer@ritcv.UUCP (Ed Reed) (10/16/86)
In article <10410@cca.UUCP> Chris Torek writes: > > 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. > I'd speculate further...more software developers (companies and individuals) have gone bankrupt because of buggy or non-existant documentation (leading to unreasonable expectations of the actual software) than because of buggy software! No scientific basis of fact, you understand, but I almost did! The problem is you have a wonderful software product, but without proper user documentation, the salesman sells something your software doesn't do, your customer tries it, finds out it doesn't work, and then sues your tail off for misrepresentation. This was a real problem during the 70s when minicomputers were proliferating. > 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'.] With regard to univerityware...what worries me more is that school is where people learn both HOW and WHAT to do...since they DON'T learn importance of software quality and documentation, it's left to industry to do it...and that's a large reason why college new-hires get so unhappy when they're assigned to entry-level coding jobs with close supervision...they haven't learned what is expected of them during their 3-4 years of school, so they'll spend 3-4 years of their careers learning it. ------------------ Standard disclaimers apply...I'm just an adjunct and a grad student actually PAYING for this mscs degree, not a real person at all. -- ------------------------------------------------- Ed Reed - Rochester Institute of Technology phone: (716) 334-3006 Delphi: EERTEST GEnie: SQA.INC Usenet: ...rochester!ritcv!eer -------------------------------------------------
bnfb@uw-beaver (Bjorn Freeman-Benson) (10/16/86)
>>(d) The software should be rigorously tested. It is not enough... > >This is the whole point of beta testing. ... No, no. The software should be rigorously tested BEFORE beta testing. Take an automobile as an example, would you beta test a new sports car if you knew that they hadn't run it on the test track themselves? What if they forgot the a crucial part in the brakes? Beta test is a crucial part of the release cycle, but it must not be the only, or even only substantitive, testing that is done. This attitude is the software engineering communinty has got to change. Bjorn N Freeman-Benson
g-rh@cca.UUCP (Richard Harter) (10/17/86)
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 :-)chris@umcp-cs.UUCP (Chris Torek) (11/02/86)
[Richard Harter] >>>(d) The software should be rigorously tested. It is not enough... [Me] >>This is the whole point of beta testing. ... In article <1874@uw-beaver> bnfb@uw-beaver.UUCP (Bjorn Freeman-Benson) writes: >No, no. The software should be rigorously tested BEFORE beta testing. True. But note that no tests of large systems are ever thorough enough. The software should be `rigorously tested' before shipping, but companies should expect, not ignore, bug reports from beta sites! >Beta test is a crucial part of the release cycle, but it must not be the >only, or even only substantitive, testing that is done. I had not meant to imply that. I guess it was a bug that slipped past the pre-posting tests. :-) [The confusion clearly resulted from differing definitions of `rigorous'. In my opinion, for example, no in-house tests of TCP/IP are ever rigorous, for there are far too many variables for any one group to characterise and test all possible effects.] -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu