🚀 go-pugleaf

In article <1992Aug21.122354.12367@cbnewsj.cb.att.com> davet@cbnewsj.cb.att.com (Dave Tutelman) writes:

   >Of course, the whole point of c.s.r is to post only software that meets a
   >standard of quality defined by the reviewers.  I'm just wondering if the
   >standard is currently set a little too high, or if there is maybe not enough
   >flexibility in the process to accommodate reviewers' opinions versus
   >authors' opinions.

   I think Tom is onto something here.  Frankly, quality IS the issue.

   When I develop software on the job, my company is going to sell thousands
   of copies of it.  Customers have expectations that it will JUST PLAIN WORK.
   If it fails to meet that expectation (1) we spend big bucks on tech support,
   or (2) worse, we lose the customer.

   For these reasons, I fully EXPECT my code to undergo:
    - Peer inspections.  ANY nitpicky suggestions, even to whether a line
      is adequately commented, is fair game and is usually honored.  We
      have a considerable set of methodology and even training in how to
      do code inspections and follow-ups.
    - Extensive testing.  A rule of thumb is that the staff-weeks of testing
      a release should approach the staff-weeks of programming it.  (And the
      programming includes unit testing anyway.)  Before the testing starts,
      there are written test plans (frequently generated with computer aids)
      including test cases and computing environments supported.

   As a PROFESSIONAL developer, I actually appreciate this "overhead".  It
   prevents quality problems later that are a much bigger headache for both
   me and my employer.

   BUT.....  I post programs to the net as an AMATEUR developer.  The things
   I post are programs I wrote for myself, on my own time.  I'm sharing them
   on the net as either:
    - A favor ("I wrote this; you're welcome to use it"), or
    - An ego trip ("Hey, look what I did").
   I'm not doing it to make a buck, and I certainly don't make promises to
   support it.  (I frequently DO fix problems, but that ain't in the contract.)
   I believe the great majority of software professionals (that is,
   non-students) on the net operate from similar motivation.


Speaking as a consumer, let me interject here that I personally don't care
what "hat" (professional vs. amateur) a developer was wearing when she wrote
and posted her code.

There are exactly TWO tests that net.software has to pass in order to be
used here.  In the tradition of classic 'C', failure of the first test
means that the second won't even be tried:

1)  The software has to work.

It is absolutely astonishing to me how many packages fail this test.  Even
when the packages come from people who CLAIM to be using the same development
environment that is used here (SunOS 4.x -- not a rare one, I hope!).

It is also kind of amazing that when people complain about this fact, they
get shouted down.  I'm not going to make too much noise on the issue for
exactly this reason.

Regardless, I feel compelled to reiterate this:  If you are a
net.software.author, and you post your amazing cool software, and some
net.software.consumer pulls it off the net, and it won't even compile on
her envionment, .......FLUSH........!


2)  The software has to be useful to someone.

This one is like gravity.  It's there, you live with it.




IMHO, the noise that's being heard about the quality standards being too
high may be accurate -- MAY BE.  The only test is going to be feedback
on (and presumably to) the c.s.r group itself.

If the quality control is good enough that people can drop it into place and
have it work, then it's good enough.  The only question remains, is the
current c.s.r standard higher than even that.  (I dunno...)



Another thing worth mentioning:  when in the "plug it in, turn it on" phase
of a new piece of software, I'd be more willing to believe that some
failure was my fault if I knew that a "Mongol Horde" of reviewers had
pounded and abused the software, and they DIDN'T have this problem...



-- 
 **************************************************************************
** DEBUGGING is no substitute for                         Austin Hastings **
*        TESTING is no substitute for                 Austin@Franklin.Com  *
*              DESIGN is no substitute for             USA+[609] 261-4800  *