RE: [AM] Article of Interest in CIO Magazine

There are other major post-deployment costs that are not so obvious, including:
- The cost of training people how to use the system properly.
- The cost of taking service calls to help people use the system properly or fix the problem created by using it improperly.
- The cost of integrating future systems with this one. (This includes the cost of the failure of some future projects because integration is too costly or unweildy, or not being able to justify starting some useful projects because of this problem).
- The opportunity costs of not being able to start an important project because this one has to be extended or remediated.
 
Steven Gordon

	-----Original Message----- 
	From: Yuval Oren [mailto:[email protected]] 
	Sent: Sun 3/7/2004 8:20 PM 
	To: [email protected] 
	Cc: 
	Subject: 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


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