home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / security / misc / 2347 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  3.1 KB
  1. Xref: sparky comp.security.misc:2347 comp.org.eff.talk:7848
  2. Path: sparky!uunet!spool.mu.edu!think.com!ames!pacbell.com!iggy.GW.Vitalink.COM!cs.widener.edu!dsinc!ub!csn!teal!bhayden
  3. From: bhayden@teal.csn.org (Bruce Hayden)
  4. Newsgroups: comp.security.misc,comp.org.eff.talk
  5. Subject: Re: Stupid Licenses (YUCK!)
  6. Message-ID: <bhayden.724865911@teal>
  7. Date: 20 Dec 92 15:38:31 GMT
  8. References: <bhayden.724495103@teal> <1992Dec18.024239.11331@news2.cis.umn.edu> <bhayden.724690634@teal> <1992Dec19.023609.26000@news2.cis.umn.edu>
  9. Sender: news@csn.org (news)
  10. Organization: Colorado SuperNet, Inc.
  11. Lines: 50
  12. Nntp-Posting-Host: teal.csn.org
  13.  
  14. charlie@umnstat.stat.umn.edu (Charles Geyer) writes:
  15.  
  16. >I agree that legal liability for buggy software is a knotty problem, but
  17. >that's not what's important.  Law suits never improve quality.
  18.  
  19. Well, I tnk that that is a matter of opinion. I think that many
  20. plaintiffs' attorneys would strongly disagree with your statement.
  21. (but of course, that is enlightened self interest at its max).
  22.  
  23. >It is fair to say that no computer company puts quality first, ahead of
  24. >featurality.  Until they do, quality will remain abysmal.
  25.  
  26. >The issue is not whether they exercised "due care" or whether they found
  27. >the last bug.  The issue is whether bug fixes for all serious bugs are
  28. >provided as a matter of course, and by "serious" here I mean anything that
  29. >affects the functionality of the software, and whether product is simply
  30. >not shipped with known serious bugs.
  31.  
  32. Not the last bug, because as we all know, that is currently not feasable.
  33. What is feasible is getting the major bugs out, and getting the bug count
  34. down to a specified level before release. This is called (or part of)
  35. quality control. Unfortunately, often marketing, and not quality control
  36. has the last say on when software goes out the door. I have seen this
  37. problem at company after company.
  38.  
  39. I think that your suggestion about not worrying about QC on the front
  40. end, just on the back end is indicative of the American mindset. That
  41. way of thinking about Quality is why I drive a Japanese vehicle
  42. .
  43. >Every time I say something like this on the net.  Industry people tell me
  44. >that economic realities (according to conventional wisdom) dictate that
  45. >deadlines come before quality.  He who ships first gets the customers.
  46.  
  47. And that is why they are wide open to lawsuits. Its a business decision.
  48. As long as you stand to make more money selling defective software, 
  49. than software that works properly, companies will continue to ship
  50. before they get the bugs out. When enough software companies have lost
  51. enough money through law suits, we will gesoftware that works properly
  52. the first time. 
  53.  
  54. Just take a software engineering course. We know how to test for bugs,
  55. how to do software QC. We just don't do it. Often the company that is
  56. shipping the premature software has a QC section. Almost as often
  57. that QC group is at some level preempted by marketing. But how does
  58. it look when I ask for that QC data when I sue you for defective
  59. software. This is what is called a "smoking gun" by attorneys.
  60.  
  61. Bruce E. Hayden
  62. (303) 758-8400
  63. bhayden@csn.org
  64.