Paul Oldfield
2004-02-26 08:19:12 UTC
(responding to Scott P)
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.
appropriate methods. The question is, when is it appropriate to
use inspection? Clearly, the answer is, when you cannot be
sure of getting adequate code quality without inspection, and
as a result the value of inspection would be greater than the cost
of inspection. That assumes, of course, that doing inspection
*would* improve the quality of code to a sufficient degree.
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. 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.
IOW, if you have access to people of quality sufficient to review
code, you may find it is more effective to use them to produce
the code and mentor the rest of the team in the process.
Paul Oldfield
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
www.aptprocess.com
any opinions expressed herein are not necessarily those of
Mentors of Cally or the Appropriate Process Movement
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org
EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com
TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------
| > | (Scott A)
| > | ... If I was working on truly critical
| > | software where a mistake is costly ... then I'd very likely
| > | insist on reviews and inspections. In these situations the risk far
| > | outweighs the cost. In the vast majority of situations this isn't
the| > | ... If I was working on truly critical
| > | software where a mistake is costly ... then I'd very likely
| > | insist on reviews and inspections. In these situations the risk far
| > | outweighs the cost. In the vast majority of situations this isn't
| > | case [where other ways] seem to result in very high quality work
| > | anyway.
| >
| > (Scott P)
| > If you're willing to limit your scope to projects where it doesn't
| > matter if you deliver defects, then I can agree with you.
|
| (J.B.)
| This is insulting. It ignores Scott A's argument entirely.
(Scott P)
Scott A said "truly critical...where a mistake is costly...where the
risk far outweighs the cost". My restatement is in line with that
statement. It wasn't meant to be insulting, just to be stark.
Scott A is saying, specifically, that these methods apply where
the cost of releasing the defects that inspections would catch is
lower than the cost of doing the inspections, which is exactly what
I would say, too. I don't think "doesn't matter" is an inaccurate
characterization of that rule - if the defects mattered more than
the cost, you would do the inspections.
You did seem to ignore the second half of Scott Ambler's| > | anyway.
| >
| > (Scott P)
| > If you're willing to limit your scope to projects where it doesn't
| > matter if you deliver defects, then I can agree with you.
|
| (J.B.)
| This is insulting. It ignores Scott A's argument entirely.
(Scott P)
Scott A said "truly critical...where a mistake is costly...where the
risk far outweighs the cost". My restatement is in line with that
statement. It wasn't meant to be insulting, just to be stark.
Scott A is saying, specifically, that these methods apply where
the cost of releasing the defects that inspections would catch is
lower than the cost of doing the inspections, which is exactly what
I would say, too. I don't think "doesn't matter" is an inaccurate
characterization of that rule - if the defects mattered more than
the cost, you would do the inspections.
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.
| This is equally insulting. I'm not sure that this furthers your
| argument. No need to puff out your chest at us.
Agilists, of course, never puff out their chests and demean
people who use traditional methods...
Let's quit while we're even...| argument. No need to puff out your chest at us.
Agilists, of course, never puff out their chests and demean
people who use traditional methods...
If you're dealing with people's money or building tools that people
will depend on in earning their money or building consumer devices
or dealing with personal data whose release or mis-reporting could
expose you to liability suits, you ARE working on software that is "truly
critical...where a mistake is costly", and you should be using
appropriate methods. I don't think that's a small niche, and I think
it's misleading to describe it in ways that imply that it is.
Of course, my personal belief is that we should *always* usewill depend on in earning their money or building consumer devices
or dealing with personal data whose release or mis-reporting could
expose you to liability suits, you ARE working on software that is "truly
critical...where a mistake is costly", and you should be using
appropriate methods. I don't think that's a small niche, and I think
it's misleading to describe it in ways that imply that it is.
appropriate methods. The question is, when is it appropriate to
use inspection? Clearly, the answer is, when you cannot be
sure of getting adequate code quality without inspection, and
as a result the value of inspection would be greater than the cost
of inspection. That assumes, of course, that doing inspection
*would* improve the quality of code to a sufficient degree.
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. 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.
IOW, if you have access to people of quality sufficient to review
code, you may find it is more effective to use them to produce
the code and mentor the rest of the team in the process.
Paul Oldfield
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
www.aptprocess.com
any opinions expressed herein are not necessarily those of
Mentors of Cally or the Appropriate Process Movement
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: gcma-***@gmane.org
EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: agilemodeling-***@topica.com
TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------