Hurray Igor!

Testing can never replace code review. The Wikipedia article on software 
peer review reports: "The National Software Quality Experiment,[2] 
evaluating the effectiveness of peer reviews, finds, "a favorable return 
on investment for software inspections; savings exceeds costs by 4 to 
1". To state it another way, it is four times more costly, on average, 
to identify and fix a software problem later."

I suspect that the figure is much higher if it is left to the end user 
to find the problem.

But this requires, of course, that the code is readable and chunkable so 
that there is something to review.

Cheers-
-Trygve

On 2010.12.17 23:52, Juan Vuletich wrote:
> Igor Stasenko wrote:
>>
>> My 2c.
>>
>> I am always wanted to have some guru who routinely checks my code,
>>  analyzing it, and letting me know if there any shitty stuff.
>> We should stay open to criticism. Otherwise we will stop learning at
>> some moment,
>> because pride turns you into stone.
>
> And you don't even need a 'guru', but a committed team. At my previous 
> job (@ CaesarSystems), every change had to be reviewed by another team 
> member. That was true even for the boss and the technical leader. The 
> reviewer could be any team member (except the author of the change 
> set). The reviewer checks that the code is sound, that it doesn't 
> break anything obvious (or any existing test), and that the mandatory 
> tests fail without the fix and pass with it. But the reviewer could 
> simply reject the code for not liking it, or not fully understanding 
> the intent. Some times, when agreement became difficult (author would 
> defend his original version, reviewer would keep rejecting it), a full 
> team meeting was done. In these, most people would have learned 
> something valuable after the discussions, and many times, better 
> designs would emerge.
>
> This is also great to have a consistent coding style that is the 
> Team's one, and not a coder's own. Code review is also a great 
> opportunity to make team members learn about parts of the system they 
> never worked on, and it avoids concentrating specific knowledge on a 
> single person.
>
> This practice was the single main factor resulting in high code 
> quality and a team with ever increasing skills. It is indeed what I 
> miss most of that job.
>
> Nowadays I code mostly alone, and the only way to emulate that 
> practice is to review my own code one or two days after I write it. It 
> works: many times I find errors, details I forgot to consider, or 
> unwanted consequences. For instance, most of the change sets in the 
> Cuis update stream get rewritten several times over several days, 
> until I'm satisfied with them.
>
> Cheers,
> Juan Vuletich
>
>

-- 

Trygve Reenskaug       mailto: trygver at ifi.uio.no

Morgedalsvn. 5A         http://heim.ifi.uio.no/~trygver

N-0378 Oslo               Tel: (+47) 22 49 57 27

Norway

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20101219/8cda82b9/attachment.htm