Re: Work to the risk was Re: Inspections Was: RE: [AM] ANN: Mashing Deadly My

| From: Paul Oldfield<[email protected]>
| 
| You did seem to ignore the second half of Scott Ambler's 
| comment, that the processes used "seemed to result in very
| high quality work anyway".
| 
| I think we can accept your point that code inspections would be
| omitted when the value they give would not justify their cost.
| I have worked on software (proof of concept prototypes)
| where high quality was not important.  Yet there are other cases
| where inspections are not justified, such as the case Scott
| Ambler outlines - the code is already of very high quality.
| 
| Not all teams doing XP or other agile approaches manage to 
| achieve this "very high quality", but some teams have reported
| exceptionally high quality.  Whatever approach, to achieve high 
| quality code needs high quality people, and after that, the choice
| is in how you leverage them to deliver high quality code.
---

I don't think I ignored it - I think the restatement embraced it.  If
the code quality without inspections is "high enough", that's fine. I
would tend to define "high enough" exactly the way I restated Scott A's
position - if the risk of releasing the code is less than the cost of
doing the inspections.

---
| 
| ...
| Yet the key improvement is in getting better people faster, as
| the quality of code depends on the quality of people, whether the 
| quality is achieved by peer review at pairing or by peer review
| at inspection.
---

This is, actually, a very interesting speculation.  I'm sure there must
be studies on the range of defect-creation rates, but I don't recall
seeing them. It would be interesting to know whether people who are
especially productive (a well-documented phenomenon) are also less
likely to create defects...
---
|  I would suggest that peer review at pairing is more
| effective at making the team better faster, because there is 
| immediate feedback not only on the code, but also on the design,
| testing and thought processes that go into producing the code.
| Inspection gives late feedback, and only on the finished product.
---

Note that I did say I thought Pair Programming was a very good practice,
even if it can't completely replace inspections in high-risk situations.

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