Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!microsoft!paulc
From: paulc@microsoft.UUCP (Paul Canniff 2/1011)
Newsgroups: comp.software-eng
Subject: Re: code reviews
Message-ID: <6110@microsoft.UUCP>
Date: 19 Jun 89 23:43:48 GMT
References: <12047@bloom-beacon.MIT.EDU> <116@opel.UUCP>
Reply-To: paulc@microsoft.UUCP (Paul Canniff 2/1011)
Organization: Microsoft Corp., Redmond WA
Lines: 37

>In article <12047@bloom-beacon.MIT.EDU> tada@athena.mit.edu (Michael Zehr) writes:
>>Since part of my job here is to improve programmer productivity, i'm
>>interested in eventually implementing some sort of procedure for
>>periodic peer reviews.  Does anyone have suggestions or
>>reccommendations?
>>
>>michael j zehr


In article <116@opel.UUCP> johnk@opel.UUCP (John Kennedy) writes:
>I can't help but chuckle when I see code reviews and productivity in the
>same paragraph.  It's good for the project, it's what the customer wants,
>but be assured that it's an increase in overhead and a decrease in productivity.
>
>I wish this weren't true.

I have the opposite opinion.  It is good for the project, it is good
for the team members, and it *does* increase overall productivity if done
correctly.  By this I mean it encourages folks to write code that they
are willing to expose to the world;  such code usually has fewer bugs,
and is better presented and easier to maintain.

If on the other hand you make an extreme case for finicky format details
and have curly-brace wars in the code review, folks will spend lots of
time formatting the source, making whitespace deltas, etc.

So, the review shakes out some bugs (fresh pair of eyes and all that),
plus it puts the fear of ridicule into the lazy programmer who write
unmaintainable code.  And, it gives programmers a chance to (1) see code
they may someday have to work on, while the original developer is there
to answer questions (and insert needed comments) and (2) learn from
each other.

The pitfalls:  too many reviewers, wrong reviewers, wrong criteria, no
follow-up on review comments, and *fear* of the review.  That last one
is a big problem;  no-one wants to be the first reviewed, especially if
the criteria and goals are not clearly spelled out.