home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / sources / d / 1227 < prev    next >
Encoding:
Text File  |  1992-08-30  |  4.9 KB  |  109 lines
  1. Newsgroups: comp.sources.d
  2. Path: sparky!uunet!twwells!frnkmth!frnk409!austin
  3. From: austin@frnk409.franklin.COM (Austin G. Hastings)
  4. Subject: Re: comp.sources.reviewed and a blast from the past
  5. In-Reply-To: davet@cbnewsj.cb.att.com's message of Fri, 21 Aug 1992 12:23:54 GMT
  6. Message-ID: <AUSTIN.92Aug29135259@frnk409.franklin.COM>
  7. Sender: austin@franklin.com (Austin G. Hastings)
  8. Reply-To: austin@franklin.com
  9. Organization: Franklin Electronic Publishers, Inc., Mt. Holly, NJ USA
  10. References: <1992Aug14.150535.15169@rick.dgbt.doc.ca> <1992Aug17.023423.14527@virtech.uucp>
  11.     <Bt5M67.273.2@cs.cmu.edu> <1992Aug21.122354.12367@cbnewsj.cb.att.com>
  12. Date: Sat, 29 Aug 1992 17:53:03 GMT
  13. Lines: 94
  14.  
  15. In article <1992Aug21.122354.12367@cbnewsj.cb.att.com> davet@cbnewsj.cb.att.com (Dave Tutelman) writes:
  16.  
  17.    >Of course, the whole point of c.s.r is to post only software that meets a
  18.    >standard of quality defined by the reviewers.  I'm just wondering if the
  19.    >standard is currently set a little too high, or if there is maybe not enough
  20.    >flexibility in the process to accommodate reviewers' opinions versus
  21.    >authors' opinions.
  22.  
  23.    I think Tom is onto something here.  Frankly, quality IS the issue.
  24.  
  25.    When I develop software on the job, my company is going to sell thousands
  26.    of copies of it.  Customers have expectations that it will JUST PLAIN WORK.
  27.    If it fails to meet that expectation (1) we spend big bucks on tech support,
  28.    or (2) worse, we lose the customer.
  29.  
  30.    For these reasons, I fully EXPECT my code to undergo:
  31.     - Peer inspections.  ANY nitpicky suggestions, even to whether a line
  32.       is adequately commented, is fair game and is usually honored.  We
  33.       have a considerable set of methodology and even training in how to
  34.       do code inspections and follow-ups.
  35.     - Extensive testing.  A rule of thumb is that the staff-weeks of testing
  36.       a release should approach the staff-weeks of programming it.  (And the
  37.       programming includes unit testing anyway.)  Before the testing starts,
  38.       there are written test plans (frequently generated with computer aids)
  39.       including test cases and computing environments supported.
  40.  
  41.    As a PROFESSIONAL developer, I actually appreciate this "overhead".  It
  42.    prevents quality problems later that are a much bigger headache for both
  43.    me and my employer.
  44.  
  45.    BUT.....  I post programs to the net as an AMATEUR developer.  The things
  46.    I post are programs I wrote for myself, on my own time.  I'm sharing them
  47.    on the net as either:
  48.     - A favor ("I wrote this; you're welcome to use it"), or
  49.     - An ego trip ("Hey, look what I did").
  50.    I'm not doing it to make a buck, and I certainly don't make promises to
  51.    support it.  (I frequently DO fix problems, but that ain't in the contract.)
  52.    I believe the great majority of software professionals (that is,
  53.    non-students) on the net operate from similar motivation.
  54.  
  55.  
  56. Speaking as a consumer, let me interject here that I personally don't care
  57. what "hat" (professional vs. amateur) a developer was wearing when she wrote
  58. and posted her code.
  59.  
  60. There are exactly TWO tests that net.software has to pass in order to be
  61. used here.  In the tradition of classic 'C', failure of the first test
  62. means that the second won't even be tried:
  63.  
  64. 1)  The software has to work.
  65.  
  66. It is absolutely astonishing to me how many packages fail this test.  Even
  67. when the packages come from people who CLAIM to be using the same development
  68. environment that is used here (SunOS 4.x -- not a rare one, I hope!).
  69.  
  70. It is also kind of amazing that when people complain about this fact, they
  71. get shouted down.  I'm not going to make too much noise on the issue for
  72. exactly this reason.
  73.  
  74. Regardless, I feel compelled to reiterate this:  If you are a
  75. net.software.author, and you post your amazing cool software, and some
  76. net.software.consumer pulls it off the net, and it won't even compile on
  77. her envionment, .......FLUSH........!
  78.  
  79.  
  80. 2)  The software has to be useful to someone.
  81.  
  82. This one is like gravity.  It's there, you live with it.
  83.  
  84.  
  85.  
  86.  
  87. IMHO, the noise that's being heard about the quality standards being too
  88. high may be accurate -- MAY BE.  The only test is going to be feedback
  89. on (and presumably to) the c.s.r group itself.
  90.  
  91. If the quality control is good enough that people can drop it into place and
  92. have it work, then it's good enough.  The only question remains, is the
  93. current c.s.r standard higher than even that.  (I dunno...)
  94.  
  95.  
  96.  
  97. Another thing worth mentioning:  when in the "plug it in, turn it on" phase
  98. of a new piece of software, I'd be more willing to believe that some
  99. failure was my fault if I knew that a "Mongol Horde" of reviewers had
  100. pounded and abused the software, and they DIDN'T have this problem...
  101.  
  102.  
  103.  
  104. -- 
  105.  **************************************************************************
  106. ** DEBUGGING is no substitute for                         Austin Hastings **
  107. *        TESTING is no substitute for                 Austin@Franklin.Com  *
  108. *              DESIGN is no substitute for             USA+[609] 261-4800  *
  109.