RE: [AM] Article of Interest in CIO Magazine

>From: [email protected] [mailto:[email protected]] 
>

>In a message dated 3/7/2004 8:25:30 PM Pacific Standard Time,
[email protected] writes:

>There are other major post-deployment costs that are not so obvious, 

>Actually, Steven, I agree, and thank you for bringing them into the
discussion. I omitted them so as not to distract my focus from the effect of
system design on post->deployment costs. Now that you have brought them up,
there could, in fact, be a direct correlation between the design of a system
and the costs you've mentioned. But >where in the agile equation does
consideration for these things fit? 

 

One factor that needs to play into design is how much it will cost to
re-factor. If it's very easy to change some functionality - if it's hidden
in an implementation class, for example - then there's no need to build in
all the requirements or try to avoid future changes. If, however, it's
costly to change, such as a public interface or API, then you need to design
it to minimize future changes to the interface.

 

>While the purists among us might suggest that we disregard those things
that are not known, because there is some likelihood that whatever work we
do on them may >ultimately be unnecessary, and therefore a waste of
resources, the "impurists" might suggest that to do nothing in the face of
seemingly incontrovertible evidence that the >system will require some level
of post-deployment maintenance or modification is irresponsible, derelict,
or worse. 

 

It also depends on how you define "known." If you know you'll need it, and
if you think it will be more difficult to add later, then you might as well
take care of it now. I feel that the deciding factor for these things should
be how much more costly it will be to add later rather than now, weight
against the chance you'll actually need it.

 

Another point to consider - and I'm sure the XP and AM folks will disagree
with me here - is the experience of your development team. If everybody
shares the "big picture," and they understand it well enough to make the
appropriate re-factoring correctly at the right time, then you should
consider yourself blessed for having such an aligned team. I've sometimes
found myself in cases, however, where it will take me less time to build the
extra feature than to explain how it should fit later. This is especially
relevant when you can't be there all the time. I've had consulting jobs
where I knew nobody would try to change the system until a year after I
left. I felt it appropriate in those situations to build up the software and
abstractions/layers so that it was very easy to add the anticipated upcoming
features.

 

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