🚀 go-pugleaf

In article <Bt5M67.273.2@cs.cmu.edu> tgl+@cs.cmu.edu (Tom Lane) writes:
>cpcahil@virtech.uucp (Conor P. Cahill) writes:
>>
>> I think the 
>> community would be much better served by a much faster and much less 
>> nit-picky mechanism that precluded a reviewer from being able to say
>> things like, "I don't like the way he did that".    
>
>Well, I think that even very nit-picky comments may be valuable;.....
>On the other hand, if the process allows a reviewer to *prevent a package
>from being posted* on the basis of minor quibbles, that is a big problem.
>There needs to be an escape that lets an author say "maybe that is a good
>idea, but I'm not going to do it"....
>
>If the hurdle is too high, I can well imagine authors submitting to c.s.r,
>reading the reviews, taking the suggestions they like, and proceeding to
>post to c.s.m or c.s.u rather than argue about the suggestions they don't
>like....
>
>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.

CSR seems to want to be a mechanism to fill in the gap between an amateur
developer and professional quality.  The question remains:

	"How many amateur developers have the patience and dedication
	to put up with what is necessary to achieve professional quality?"

I dare say very few.  I know I wouldn't, in my amateur status.  Students who
have never been part of a professional team don't even realize what the
difference means.  I believe much of the debate here is this very issue.

Hope this generates more light than heat.

Dave