Re: [AM] Article of Interest in CIO Magazine

Hubert:

You've given a good example of this point. When I was in the U.S. Air Force, 
I learned quite a bit about the "Hurry up and wait" philosophy, which 
incidentally, may be a derivative of the "instant gratification" thing. I can't tell 
you the number of times I've been forced to sit through seemingly endless 
meetings in which some I.T. worthy drones on and on, giving the intended users a 
litany of how great their system is going to be, with me wanting to stand up and 
tell the users that there is absolutely no way Mr. I.T. can make these claims 
with with any real certainty. 

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). The former is typically the result of simply running afoul 
of the schedule, in terms of development cost (including the cost of change 
orders) or time (as in, running out of it) to deployment. The latter is 
typically reflective of the number and scope of the modifications to the system to 
satisfy emerging requirements. Given that post-deployment remedial work is often 
estimated to be 100 to 1000 times the cost of the same work during the 
development process, some component of the post-deployment cost must be related to 
the degree of difficulty of adding features. 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. Worse yet, in my nearly thirty 
years of development experience, 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. My point is that while predicting the future regarding the uses to be 
addressed throughout the lifetime of a system might be impossible, designing a 
system architecture that minimizes the effects of change is not, and even the 
smallest design concession to maintainability and sustainability can pay huge 
dividends throughout the lifetime of the system. If this is true, what factors are 
present in the software development process employed today that seem to be 
preventing these systems from being built? The statistics regarding lifetime 
costs have not changed appreciably over the past several years, so what's the 
deal? What factors can be identified that distinguish the low-maintenance systems 
from others? Despite the flood of new and improved development tools that 
enhance collaboration, communications, and productivity (and will probably 
brighten our smiles and even reduce foot odor in the next release), post-deployment 
costs remain stubbornly high. It has always seemed to me that focusing on 
reducing development costs is looking through the wrong end of the telescope. 

O.K., I'm stepping down off my soapbox. What do you guys think about this 
syuff?

>> End of Rant <<

Regards, 

Pete

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