[LA.pm] contrasting London and LA

[Geoffrey Young]

> Based on lots of theory, I believe that a good solution to
> both problems is to use lots of code reviews - don't let
> any code go into production without having it reviewed.
> This both limits damage from junior programmers and causes
> lots of mentoring to happen.  Which also means that junior
> people don't remain junior for long.  There are other
> benefits, for instance IBM's research indicates that code
> reviews are the most cost effective form of QA.
> 
> But as great as the theory is, I don't have much practical
> experience with that approach.  And there are drawbacks.
> Primary among them being the fact that many programmers
> will get upset when their code is reviewed by someone else
> in detail.  Plus the visible overhead is hard for a lot of
> people to swallow.  Still I'd like that environment.

I worked for a few years at andersen consulting (which has since been
renamed accenture) and we did just that - _every_ piece of code went
through a _formal_ code review process before it hit production, where
we all got packets (sometimes very large packets) and went over the code
line by line, discussing lesser things like style and conformity, to
drawing on people's experience, both as just plain coders as well as
people who understood the systems we were integrating with.

yeah, it was an intensive process, but we were consultants so we just
billed for it :)  but the culture was there from the get-go for me, so I
never saw a programmer get upset by the things that came out of the code
reviews, and never got upset myself.  but I can see how trying to
enforce that kind of environment where one doesn't exist currently could
be, um, difficult.

then again, much of the open source project world works like a never
ending code review, with people sometimes being far less "corporate"
about their opinions.  so if you are already of the mind to hire people
with open source experience, people used to sending in patches and
reworking them and, in general, fitting in with a project and whatnot,
then it shouldn't be that hard to figure out how to institute some kind
of code review.  personally, I see commit emails as a very simple way to
go about this, since it's a format lots of people are used to and the
review and discussion can happen naturally... for those willing to take
the time to read the diffs :)

anyway, just some random thoughts late on a friday night :)

--Geoff