I'm revamping my How To Be Lazy tutorial for 2002 with an eye towards
making it a collection of techniques which are easy to learn, easy to
teach, easy to accept and hard to screw up.  I'm stuck on code review
alternatives.

Essentially, I'm looking for a way to make sure:

    Stupid mistakes in code get caught
    Tests get written and have decent coverage
    Code style isn't attrotious
    No one programmer gets tunnel vision and cranks out a load of crap
    Everyone gets some familiarity with the whole code base
    Experienced programmers work with inexperienced and vice-versa.

I know of two good ways to do this, but none meets my criteria.  One
is Pair Programming, the other is Mandatory, Managed Code Reviews.


Pair Programming does all the above to some extent.  Its easy to
learn, easy to teach (by its very nature) and fairly hard to screw up.
Unfortunately, many people find it hard to accept, especially
management ("You mean you want two programmers doing the job of one?!") 
so its unsuitable for my needs.


Mandatory, Managed Code Reviews is basically where each individual
change is reviewed by another member of the team before being
committed.  Its Mandatory because *all* changes are checked (using the
honor system or something like Aegis).  Its Managed because people are
assigned/take review tasks each day (again, by ad hoc or using
something like Aegis).

We used it at Blackstar (AFAIK they still do, Tony?)  When it worked,
it worked great.  Problem is if the daily management of the system
slipped the whole system became a detriment.  Basically, left to
ourselves, we would rather code than review.  So review tasks piled
up, and code couldn't be committed until it passed review.  So unless
changes were reviewed promptly work would stall.

There were other problems.  We tended to grab the easy reviews and
avoided the hard ones.  We tended to use reviews as a crutch to find
stupid mistakes and got a bit sloppy when coding.

So if the management of the review system gets lax, the whole system
comes apart.  Therefore it fails the "hard to screw up" requirement.
(You guys solve any of this, Tony?)


So I'm looking for something like the above, but that meets my
criteria of being easy to learn, teach, accept and hard to screw up.


-- 

Michael G. Schwern   <[EMAIL PROTECTED]>    http://www.pobox.com/~schwern/
Perl Quality Assurance      <[EMAIL PROTECTED]>         Kwalitee Is Job One
gleam comes to my eyes
as I combine pure water
and triticale.
        -- mjd

Reply via email to