Re: [AM] Code reviews preventative?

By "code branch" I mean a private view of the code (which would be
shared by people working together on the code).  By "integrate" I mean
"release for use by others with a promise that it is known to work".
In our environment (ClearCase) that would mean moving the code to
the main line.

"Integration" may mean different things to different people. Our process
would typically involve (a) the developer working with the code on a
private branch, (b) the developer unit testing the code on that branch,
(c) the developer synching the branch with the main line by merging any
main line changes down into the development branch (pre-integrating),
(d) the user building the whole system and running a defined set of
integration tests, (e) the user moving the code to the main branch, (f)
the user doing a system build and running the integration tests again,
(g) the configuration management team moving the label to the new
version.  We would call (g) "Integrated". Inspections would usually
happen between after (c) and before (e), the exact point depending on
the project and the specifics of the development (based on an evaluation
of the risks involved).

Note that going to smaller cycles reduces the time spent in steps (a)
and (b) (and, therefore, the probability of interfering integrations
requiring merging), but if ALL the developers are doing several
integrations a day, that drives the risk or interference right back up.

Our rule is that code is never allowed on the main line (where others
will pick it up in their builds) until it has been inspected and built
on the development branch.  Breaking the build is a major sin.

If you're really integrating several times a day, then the integrations
must be small, so the inspections would also be small.  You could also
batch the inspections (have one group of inspectors do several small
readings in one session).

scott



| From: "J. B. Rainsberger" <[email protected]>
| 50 -0500
| Date: Tue, 03 Feb 2004 18:36:11 -0500
| 
| Scott E. Preece wrote:
| > | From: "J. B. Rainsberger" <[email protected]>
| > | 
| > | Scott E. Preece wrote:
| > | > Presumably pair programming similarly doesn't keep defects from being
| > | > written, it just identifies them faster (the person typing is still
| > | > going to type the error before the person reading can see what was
| > | > typed). [I recognize that in some cases the pair will recognize the
| > | > defect in discussion before typing, but that kind of incidental save is
| > | > no more preventative than a single programmer re-reading her code before
| > | > submitting it for testing - some defects simply don't live long enough
| > | > to reach the metrics.]
| > | 
| > | Agreed: it's just a question of where we find the defect. I placed the 
| > | dividing line at "did we integrate yet?" which is releasing to the rest 
| > | of the team. You placed the dividing line at "did we release to the 
| > | customer yet?" I think there's a considerable difference between the two.
| > ---
| > 
| > I'm missing what you're trying to say here - inspections would normally
| > be done before integration (that is, before the code branch switches
| > from private to public).
| 
| "Code branch"?! I don't want to get into a discussion of code branches.
| 
| It appears that you're saying we inspect code before we integrate it. 
| That's already several times per day on my projects. If we're inspecting 
| code that often, we might as well do it continuously: the 
| context-switching costs of running three-to-five code separate 
| inspections per programmer per day are quite high.
| -- 
| J. B. Rainsberger,
| Diaspar Software Services
| http://www.diasparsoftware.com :: +1 416 791-8603
| Let's write software that people understand
| 
| For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
| 
| 


-- 
scott preece
motorola urbana design center (il67), 1800 s. oak st., champaign, il  61820  
e-mail:	[email protected]	fax:	217-384-8550
phone:	217-384-8589	cell: 217-433-6114	pager: [email protected]

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: [email protected]

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: [email protected]

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------