RE: [AM] Article of Interest in CIO Magazine

Hello all. I just joined this list. What a great discussion!

 

            Pete wrote:

 

IMHO, the major contributors to post-deployment costs are comprised of
remedial work (those costs related to fixing problems that should have been
detected and fixed during the development process, or adding features that
were intended to have been in place at deployment), and
enhancement/extension work (adding features intended to satisfy requirements
that were not known or foreseen during development).

 

I think you have to examine each of these post-deployment costs
individually:

 

Fixing bugs not detected during development:

 

Sometimes this is a business decision; it may be a better move to release
your product now and fix the rest of the bugs in a later release. If this is
not the case, then it's probably of a sign of a deeper problem. Maybe the
test strategy is not sufficient, or maybe there's a fundamental design
problem that makes it more susceptible to problems. Test-driven development
is supposed to help this.

 

Adding features and enhancements after initial deployment:

 

Why is it more expensive to add these features in a second release? If
you're lucky enough to know *all* the requirements up front, then great, but
in my experience this is rare. So, one strategy is to try to minimize the
cost of deployment - automate more, etc. This is one of the key objectives
of agile processes, right?

 

I've also found in my experience that the development cost of adding
features is directly related to the "quality" of a design. In fact, I think
one way to measure the quality of a design is to see how much upheaval is
necessary to add unexpected features. I like to ask a lot of "what if you
needed to add this new feature"-type questions when evaluating a proposed
design. If you'll need to rewrite everything, that's probably a problem.
Incidentally, I've never been satisfied with how development methodologies
address the issue of promoting design quality. Does anyone have any thoughts
on this?

 

 

I suspect that a significant portion of this last cost is due to the
developers having designed an architecture that is innocent of any knowledge
regarding the true lifetime costs of complex automated systems. That is,
they simply do not understand the importance of building maintainable and
sustainable systems.

 

Yes. I believe it's possible to build a badly design system no matter what
methodology you use. I doubt there's a magic bullet here. I suppose your
hiring process has the greatest effect on this point. But, good
communication and all the other agile principles can't hurt.

 

I have almost never had anyone, other than myself, suggest that the
anticipated lifetime costs of the system be assessed and taken into account
prior to the "closing the book" on the design of the system.

 

I agree, and I believe it's often because the people who must maintain the
system are often not involved in setting the product priorities. Also,
everyone is under heavy time pressure to finish the project and doesn't
really care if it will cost more later. However, is this really a bad thing?
Aren't you more likely to correctly identify your maintenance issues after
deployment than trying to guess them pre-deployment? Why not just wait until
you start to feel the pain and then fix it?

 

-Yuval

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