Defending the Python lanuage...

[Cliff Wells]

On Tue, 5 Feb 2002 08:53:27 +1100
Peter Milliken wrote:

> > I believe that the "continuous ongoing code review" being mentioned is
in
> > reference to the Extreme Programming practice of pair programming --
all
> code is
> > written jointly by two people, sitting at the same computer.  Thus,
> everything
> > is, in effect, being reviewed by the other person as it's being
written.
> This
> > should (in principle ;) ) greatly reduce the need for formal group
> reviews...
> > though I expect they'd probably still be desirable regardless.
> >
> >
> Really? What an unusual idea - I didn't realise we had such a surplus of
> programmers to advocate something like this :-)

This is a little more "extreme" than I was referring to as well.  The idea
of two programmers sitting at the same computer doesn't really go over well
with me... I was referring having two programmers sit side-by-side at
separate computers, working on different parts of the same program versus
having one programmer work in isolation.  Indeed, I don't know many
programmers with the patience to sit and watch someone else type ;) 
However, if they are each writing code for the other to use, then you get
many of the same benefits as code review and faster development to boot.  I
have nothing against "official" code review per se, but I suspect it falls
in the realm of things that are great but rarely happen.  Additionally, I
think there are side-benefits in productivity and morale when working in
pairs that aren't to be had many other ways.

> 
> Actually, it is just another attempt at fixing the same old problem. I
have
> no problems with trying new techniques such as these but at the end of
the
> day, if good old fashioned reviews are done properly (and in a timely
> manner! :-)) then you would achieve the desired effect i.e. solid, robust
> code. If the individuals involved approach the problem with the correct
> frame of mind then I have never, ever seen inspections/reviews fail! It
is
> only when it is not tackled with the right sort of commitment that it can
> appear not to work.

Exactly.  I still venture that they won't ever be "tackled with the right
sort of commitment" because it's no fun having to read other people's code,
and lack of enthusiasm always seems to win over policy and "requirements"
in the end...


> I get somewhat frustrated sometimes when I look at yet more attempts to
> solve the same problem when I believe there are already workable
solutions
> (this will, I am sure be disputed :-) but is only a statement based upon
> personal experience :-)). I think it is most likely the lack of
> self-discipline (in programmers, not themselves) that caused the authors
to
> look for alternative methods - also, the fact that they needed something
new
> to write about otherwise they wouldn't be able to publish a book! :-) I
must
> admit that in a weak moment, I purchased a copy of Extreme Programming, I
> read it on the train one evening (not the whole book! :-)) and saw enough
to
> make me put it where it is now, on my shelf gathering dust :-).

I haven't read much beyond magazine articles regarding XP myself, but I
suspect they realize the futility of traditional approaches (not that the
approaches wouldn't work... people just won't use them which amounts to the
same thing) and tried to develop new approaches that mirror what successful
developers do already.  For example, the "make one to throw away" approach
is something that most of us do already (or should, I've had _very_ few
projects where the spec was so perfect and my understanding of the tools so
complete that I've gotten it perfect the first time), they just made it
into a "formal" design phase. 

-- 
Cliff Wells, Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 x308  (800) 735-0555 x308

"Then with your new power you'll accomplish all sorts of cool stuff 
 in no time, and We'll All Be Sorry.  At that point you can either 
 gloat a bit, and then relent, or go ahead and send the robot army 
 after us." - Quinn Dunkan