Defending the Python lanuage...

[Peter Milliken]

"Alex Martelli" <aleax at aleax.it> wrote in message
news:Wls68.14178$om6.357057 at news1.tin.it...
> Peter Milliken wrote:
>         ...
> > Actually, if you are *good* at what you do, then code review, whilst
still
> > beneficial, is not nearly *that* beneficial. Things like code review
(IMO
> > :-)) is there for the 25-50% of programmers who just plain shouldn't be
in
> > the industry - what they generate is just absolute garbage - code review
> > will hopefully stop the code from getting into Unit test and beyond the
> > point of redemption :-).
>
> I disagree.  Code review, or even better the "continuous ongoing code
> review" that's such a substantial part of the benefits of pair
programming,
> is in my experience just as beneficial with the best coders: without it,
> besides bugs, it's far too much a temptation to pepper the code with
> clever tricks, individual style quirks, unexamined (subconscious)
> assumptions about inputs and environmental conditions, and the like.
>

I doubt that you really "disagree" Alex with what I say, you certainly
disgree with what you *think* I say :-). Mine is not an absolute statement,
it is relative to a certain situation and is very heavily qualified (not the
use of "nearly" etc). I think we are both completely agreed that code
reviews, when done properly and in the right "spirit" will always be
beneificial to all parties involved. As for "pair" - I happen to have
experience that indicates that reviews should *always* be conducted by 3 or
more people and the results communicated via a "formal" sit-down meeting.
The "3 or more" because the more people involved the more that will be
picked up (not everybody thinks of everything) - this of course has to be
tempered by practicalities such as you can't have all 10 programmers on the
project reviewing the same code :-). To my mind (opinion here :-)), the
ideal is 2 to 3 reviewers, the author and possiby a "junior" who is
nominally a reviewer but is really there for the experience i.e they
generally do not have much useful input to the review i.e. no more than 5
people in the room - tops. I have worked at getting various groups I have
worked with doing reviews ever since I was first introduced to them back in
1985 - so I have about 17 years (on and off) with getting people to do them
(or trying to) and the various forms that people come up with when
attempting them :-).

The "formal" meeting part is necessary to achieve a group synergy which just
doesn't happen when passing around pieces of paper with other people
comments i.e. this is the idea of the sum of the parts are not greater than
the whole. I have reasonably extensive experience with a number of different
review techniques (the so called round robin, the just pass the comments
back to the author etc) and none of them work nearly as well as "the 3 or
more with a meeting". Of course, many people would scoff or denigrate the
meeting because they feel meetings are a waste of time - these are the
people who lack the self discipline to get in there, do the job and get out
i.e. they are the ones who go into a meeting and start it by asking how your
weekend was, discussing how the Packers went in the game on the weekend etc
:-). A simple course on meeting techniques generally fixes this problem.

> The code coming out of a good review, or a good-synergy pair, is
> thus of much higher quality and more valuable than the results of a lone
> coding session of even a very good coder.
>

No dispute :-).

Peter