From: Stewart Stremler <[EMAIL PROTECTED]>
begin quoting Andrew Lentvorski as of Sat, Dec 09, 2006 at 10:30:28AM
-0800:
> Stewart Stremler wrote:
>
> >And you're right, it doesn't _find_ more bugs -- but if you have
> >compatible programmers, it *prevents* bugs. Mostly due to greater
> >adherence to discipline (like writing good comments, writing unit
tests,
> >choosing good variable/function names, etc.), I think.
>
> The evidence suggests that the bug rate is the same.
Hm. Personal experience suggests otherwise -- perhaps on average, across
all developers, indicates that non-compatible programmers generate more
bugs together than alone. I could buy into that.
My personal experience is that paired bug rates are at least 2x- the
developers expect the other guy to catch mistakes, and thus end up not
really thinking things through enough. Syntax errors are found at a faster
rate, but the compiler finds those anyway.
> Now, there may be benefit to sharing knowledge about style discipline.
It may be that pair-programming works best for this sort of knowledge
transfer, and should be restricted to that, rather than adopted as an
all-the-time approach.
Its still highly inefficient at it- it requires the full time of 2 people,
one of them experienced. Its far better to have good documentation which 1
person can read while the other does real work. The pro can then be
questioned as needed. As a bonus, the documentation can be used in the
future again, meaning for a small cost in writing it you get huge returns
over pairing.
The one exception I can think of us someone straight out of college who
needs to be taught how to work in the real world. SHort of that, pairing is
a waste of time.
> However, I have found that design reviews and having to fix existing
> code are generally good enough for that.
I'm in a process-oriented shop at the moment that has design and code
reviews, and they aren't working (well, they are, we're catching
problems, but the problems that are being caught are long after the
point where it is easy to fix said problems). There's so much process
that there's hardly any time left to write code...
Thats the problem- the process. Processes exist to either get things done,
or to improve quality. Thats why you follow them. If you're following the
process because its the process, you're wasting everyones time.
I find most places get code reviews wrong, using heavily formal methods and
roles and all sorts of garbage. Amazon tends to do them right. Here's our
method
1)Programmer writes code, but does not check it in
2)He sends the changes to his teammates (we use a web based tool to do
automatic diffs, but it isn't needed)
3)One or more teammates look at it, and mail any comments on it. Comments
should be potential bugs, anything thats unclear (meaning it should be
commented), bad variable names (but don't be anal here), or alternate
approaches. They should not be about where to put the braces, how many
spaces he indented, etc
4)The programmer either defends his choices, fixes things, or suggests a
comprimise
5)Repeat 3 and 4 until all are happy
6)Check in code. Notice this comes after the review.
Note the lack of any roles, formality, and meetings. These are what enable
code reviews to get done in a reasonable amount of time
Design reviews should be done on anything taking a week or more, to catch
bugs up front. These should be done by
1)Figure out what needs to be done
2)Write a quick document on it
3)Have a 1/2 to 1 hr meeting with your team
4)Answer any questions, concerns
5)If needed cue to concenrs, loop on 3
Then code and do the code review at the end.
Gabe
_________________________________________________________________
MSN Shopping has everything on your holiday list. Get expert picks by style,
age, and price. Try it!
http://shopping.msn.com/content/shp/?ctId=8000,ptnrid=176,ptnrdata=200601&tcode=wlmtagline
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
