From: agc@bmdhh286.bnr.ca (Alan Carter)
Newsgroups: comp.software-eng
Subject: Code Reviews (was SE going offshore?)
Date: 17 Nov 92 17:21:39 GMT
Organization: BNR-Europe-Limited, Maidenhead, England

In article <6962@dove.nist.gov>, bagwill@swe.ncsl.nist.gov (Bob Bagwill) writes:
|> Judd Jones (jov@styx.ornl.gov) wrote:
|> : (I note that even a 20:1 productivity differential cannot overcome
|> : a greater than 20:1 cost differential, so greater per capita domestic
|> : productivity may not be terribly relevant.)
|> 
|> Here's something to consider:
|> 
|> Q: What's the most effective method for catching design and
|>    coding problems?
|> 
|> A: Group code reviews.
|> 
|> Q: What's the most [upfront] expensive method for catching design
|>    and coding problems?
|> 
|> A: Group code reviews.
|> 
|> Q: What technique is easiest to apply if you have skilled,
|>    highly-motivated low-paid workers with little hardware or
|>    software support?
|> 
|> A: Group code reviews.
|> 
|> A U.S. company could hire a bunch of local marketeers and
|> superprogrammers to do the design and then group review the code with
|> cheaper non-local labor until it's six sigma.

I have found that group code reviews are less effective than individual 
inspection these days. Group reviews are done with listings and it is very
hard to pay attention to every little line or side effect. When code
reviews got into vogue, simple cost meant that the reviewers didn't 
have terminals in front of them. So reviewers don't have access to the
simplest automated search programs when criticising the code. Many groups
now make a virtue of the absence of terminals. 

Using a symbolic debugger like dbxtool or CodeCenter one can single-step 
one's code and actually watch it do its things. This naturally focuses 
attention on each line as it is executed, and it is often possible to spot
things like ill-formed expressions that will make conditionals go the 
wrong way under certain circumstances, even while watching them go the 
right way for other test data. This and a listing (to be crossed out in 
red crayon) provide all that is needed for really detailed, 100% code 
coverage, code inspection. Also, I can single-step for longer than anyone 
can code inspect, and my keenness does not diminish until I get tired. 
This is because watching one's own program work is fun, whereas code 
inspections are very boring.

I don't run programs any more when I get them compiled; its into the 
debugger and test the stuff straight away. I still have to go to code 
inspections of course; that's policy. But the only changes I've had 
logged against me in a code inspection this year (although the same 
change was specified several times) has been 'I think we need more 
comments here'.  I'm not convinced that the extra comments really were 
needed; people seem to need to find *something* at every code inspection. 

My fault report rate from the testers is similarly low, but my fault 
discovery rate during single step testing is still depressingly high. 
I seem to have reached a plateau of being able to type in straight code.
The mistakes go in, but the use of the symbolic debugger in this way gets
a very high proportion of them. 

I can single step perhaps slightly faster than a reader can paraphrase. 
Take a typical code inspection involving 4 people, for 2 hours, with 1
hour of prep and 15 minutes of sitting-down overhead per person, and we
have a cost factor of 6.5 over code inspections, with an error detection
rate that is at least as good, and probably better. 

   Alan

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To arrive at the simplest truth, as Newton knew and practised, requires years
of contemplation. Not activity. Not reasoning. Not calculating. Not busy 
behaviour of any kind. Not reading. Not talking. Not making an effort. Simply 
bearing in mind what it is one needs to know.

   George Spencer-Brown, Laws of Form
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~