Re: [AM] Code reviews preventative?

Your assertion is a bit absolute.  Even in
high-communication environments, mistakes can be made -
simply because of a difference in a recent experience
for instance, which primes the developers' thought
processes in such a way information is lost.

There are many objectives in and motivations for code
reviews - such would have to be defined, depending on
the complexity of the system before any such statements
can be made.  Also, I suspect the veracity of such a
statement even if both programmers are experts in the
domain and technology, which in my experience is seldom
the case.  

For instance, both in a development-pair team can be
slack on standards requirements for code, if they exist
(e.g. FAA, FDA); or inexperienced with a specialty in
the problem domain or technical domain.

Code reviews can bring experts in to catch such things
while potentially shedding light on details missed just
because we are human.

Even if we were connected to the Borg Collective of a
super efficient software development Tiger team, we can
still get in the way. 

Mark.

On Tue, 03 Feb 2004 07:57:38 -0500, Scott Ambler wrote:

> 
> 
> Compensatory, not preventative, might be the word that
> everyone is looking 
> for.  Reviews & inspections compensate for
> low-communication environments 
> where insufficient numbers of people work on the item
> being reviewed.  In 
> high-communication, collective ownership,
> pairing/working with others type 
> environments this mistake isn't made and therefore
> there isn't much value 
> in compensating for it with an inspection/review.
> 
> - Scott
> 
> At 04:20 PM 2/2/2004 -0600, you wrote:
> 
> >Depends on your definition of "preventative" - the
> purpose of code
> >inspections is to prevent defects from escaping the
> phase (and,
> >ultimately, to the customer).
> >
> >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.]
> >
> >Training and tools can be preventative in the sense
of
> keeping defects
> >from occurring to begin with.  Test-first coding
might
> help in some
> >cases (if the coder is also writing the tests and
> learns in writing the
> >test what the code has to do to pass the test).
> >
> >scott
> >
> >| From: "J. B. Rainsberger" <[email protected]>
> >| 50 -0500
> >| Date: Mon, 02 Feb 2004 16:47:14 -0500
> >|
> >| Adrian Howard wrote:
> >|
> >| > On Friday, January 30, 2004, at 08:41  pm, Randy
> Miller wrote:
> >| > [snip]
> >| >
> >| >> Some activities, like code reviews, are
> >| >> clearly preventative. They keep people from
> making mistakes.
> >|
> >| With respect, code reviews are the exact /opposite/
> of preventative:
> >| they are clearly post-mortem activities.
> >|
> >| A code review happens after the code has been
> written. By definition, it
> >| cannot be preventative. It can only hope to reduce
> the likelihood of a
> >| particular class of mistake /recurring/.
> >|
> >| Pair programming is preventative: it is a code
> review that occurs before
> >| the code is even compiled, at a stage when the
> participants are actually
> >| both willing and able to make changes.
> >| --
> >| 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
> 
> ====================================================
> Scott W. Ambler
> Senior Consultant, Ronin International, Inc.
> www.ronin-intl.com/company/scottAmbler.html
> 
> www.agiledata.org
> www.agilemodeling.com
> www.ambysoft.com
> www.enterpriseunifiedprocess.info
> www.modelingstyle.info
> www.ronin-intl.com
> 
> For more information about AM, visit the Agile
Modeling
> Home Page at www.agilemodeling.com
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"The significant problems we face cannot be solved at
the same level of thinking we were at when we created
them." - Albert Einstein

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
--^----------------------------------------------------------------