jfh@rpp386.cactus.org (John F. Haugh II) (10/23/90)
In article <1990Oct22.231028.24623@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >Considering the number of things in (to pick purely random examples :-)) >SVR4 and SunOS 4.1 that clearly were never tested, I fear Chris is being >naive. Would that it were not so. I think Henry is being equally naive - if a vendor were required to fix every last bug prior to shipping a new release, we'd still be running on ENIACs. I constantly struggle with my current client trying to force more fixes into the latest release, only to be told that the release has to be shipped some day and that the latest bug I found doesn't merit holding an entire release. And of course some things just never get tested because the vendor would rather forget they even have the code. The "ged" command comes to mind as one example. There is more to shipping product than finding bugs and fixing bugs - one must eventually decide it's soup and send it out to the masses. -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org "SCCS, the source motel! Programs check in and never check out!" -- Ken Thompson
henry@zoo.toronto.edu (Henry Spencer) (10/24/90)
In article <18632@rpp386.cactus.org> jfh@rpp386.cactus.org (John F. Haugh II) writes: >>Considering the number of things in (to pick purely random examples :-)) >>SVR4 and SunOS 4.1 that clearly were never tested, I fear Chris is being >>naive. Would that it were not so. > >I think Henry is being equally naive - if a vendor were required to fix >every last bug prior to shipping a new release, we'd still be running on >ENIACs... I don't ask that they be fixed; what I ask is that glaringly obvious bugs like "tar simply doesn't work" be noticed and documented. Shipping an imperfect product is inevitable, but shipping code that could not possibly have shown any signs of working denotes either complete lack of interest in the customer or gross carelessness. -- The type syntax for C is essentially | Henry Spencer at U of Toronto Zoology unparsable. --Rob Pike | henry@zoo.toronto.edu utzoo!henry
darcy@druid.uucp (D'Arcy J.M. Cain) (10/25/90)
In article <18632@rpp386.cactus.org> John F. Haugh II writes: >In article <1990Oct22.231028.24623@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >>Considering the number of things in (to pick purely random examples :-)) >>SVR4 and SunOS 4.1 that clearly were never tested, I fear Chris is being >>naive. Would that it were not so. > >I think Henry is being equally naive - if a vendor were required to fix >every last bug prior to shipping a new release, we'd still be running on >ENIACs. Of course some things will get out with a bug or two but that doesn't excuse the vendor that lets software out the door without even trying to find all the bugs. To expand on Chris' example of the car with no engine, someone should get in the car at the end of the line and turn the key. They might miss the fact that there is a vaccum hose missing somewhere but if a car gets out without an engine then its pretty obvious that no testing at all was done. The same with software. If you run a system utility and it immediately dumps core then you can safely say that someone didn't do their job. If it dumps core only when run at the stroke of midnight then you can say it has a bug but you can understand why it wasn't caught by the testing group. >[ ...] >There is more to shipping product than finding bugs and fixing bugs - one >must eventually decide it's soup and send it out to the masses. Agreed but that point should be somewhat later than the first time make doesn't return a syntax error and that's all Chris and Henry (by my reading) were implying. BTW: Why did you set follow ups to poster? Did you feel that no one could possibly have anything to add to this subject after you posted? -- D'Arcy J.M. Cain (darcy@druid) | D'Arcy Cain Consulting | I support gun control. West Hill, Ontario, Canada | Let's start with the government! + 416 281 6094 |
shwake@raysnec.UUCP (Ray Shwake) (10/26/90)
darcy@druid.uucp (D'Arcy J.M. Cain) writes: >The same with software. If you run a >system utility and it immediately dumps core then you can safely say that >someone didn't do their job. If it dumps core only when run at the stroke >of midnight then you can say it has a bug but you can understand why it >wasn't caught by the testing group. Agree completely. A somewhat different problem involves failure to test components of a package already in wide use. The assumption is that, if the package has been around long enough in enough hands, it's *got* to be stable, right? Often true, but not always. Many years ago I was working on PWB Accounting on a System III Zilog. After much frustration trying to resolve a problem involving the monthly update procedure, I traced the culprit to a missing comment quote in 'monacct'. Some time later, I was playing with a Plexus - nice box at the time. Found the same bug. A year or two later got my hands on the first IBM RT. Guess what... the bug was still there! Each vendor worked from common source; that vendor presumably tested his enhancements and customization, but assumed everything else *had* to be OK. Though the above sample bug and fix was reported to each vendor, I wonder how many boxes still carry it.
minow@mountn.dec.com (Martin Minow) (10/29/90)
In article <1990Oct24.164257.20928@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >In article <18632@rpp386.cactus.org> jfh@rpp386.cactus.org (John F. Haugh II) writes: >>I think Henry is being equally naive - if a vendor were required to fix >>every last bug prior to shipping a new release, we'd still be running on >>ENIACs... This is not necessarily a bad thing. In the 1960's worked for several years on a grandchild of Einiac (Eniac > Besk > Trask) that had a totally bug-free Algol-60 compiler (with prototypes and all). Rumor was that it had been written by E. Dijkstra. >Shipping an imperfect product is inevitable. I respectfully disagree with my esteemed collegue. Perhaps more importantly, I worry that it is dangerous to accept "inevitable imperfection" as it does not set a suitable goal for system/compiler/application developers. The problem is, however, that bug-free code is often invisble (my digital watch is bug-free, but I don't think of it as "software.") Martin Minow minow@bolt.enet.dec.com
diamond@tkou02.enet.dec.com (diamond@tkovoa) (10/29/90)
In article <116@raysnec.UUCP> shwake@raysnec.UUCP (Ray Shwake) writes: |darcy@druid.uucp (D'Arcy J.M. Cain) writes: ||The same with software. If you run a ||system utility and it immediately dumps core then you can safely say that ||someone didn't do their job. If it dumps core only when run at the stroke ||of midnight then you can say it has a bug but you can understand why it ||wasn't caught by the testing group. | Agree completely. A somewhat different problem involves failure |to test components of a package already in wide use. The assumption is |that, if the package has been around long enough in enough hands, it's |*got* to be stable, right? Often true, but not always. I agree too. In fact, since this topic deserves to be discussed, I have redirected followups to comp.misc (which I read) rather than alt.flame. [Disclaimer: This is my opinion, not my employer's opinion.] -- Norman Diamond, Nihon DEC diamond@tkov50.enet.dec.com (tkou02 is scheduled for demolition) We steer like a sports car: I use opinions; the company uses the rack.
henry@zoo.toronto.edu (Henry Spencer) (10/30/90)
In article <1994@mountn.dec.com> minow@mountn.UUCP (Martin Minow) writes: >>Shipping an imperfect product is inevitable. > >I respectfully disagree with my esteemed collegue... I should have been more explicit about this. It is not physically impossible to ship a product with zero bugs, but I don't think doing so is commercially viable in a competitive market at the present time. The problem is that the customers react much more negatively to delays than to bugs, so you make much more money by shipping imperfect code sooner. Indeed, in certain areas commercial success seems to be completely a matter of price, schedule, and the length of the feature checklist, with the quality of what's on the disk entirely secondary. >Perhaps more importantly, >I worry that it is dangerous to accept "inevitable imperfection" as it >does not set a suitable goal for system/compiler/application developers... Unfortunately, goals for developers tend to be set by the Marketing Dept... -- "I don't *want* to be normal!" | Henry Spencer at U of Toronto Zoology "Not to worry." | henry@zoo.toronto.edu utzoo!henry
bright@nazgul.UUCP (Walter Bright) (11/01/90)
In article <116@raysnec.UUCP> shwake@raysnec.UUCP (Ray Shwake) writes:
<The same with software. If you run a
<system utility and it immediately dumps core then you can safely say that
<someone didn't do their job. If it dumps core only when run at the stroke
<of midnight then you can say it has a bug but you can understand why it
<wasn't caught by the testing group.
I am sometimes surprised at finding a major bug in a utility or library routine
and wonder why the test suite didn't catch it. Turns out that the *only* thing
that worked right was the *exact* test case. Sigh. Test suites are never done!