struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject RE: [OT] Upgrading existing applications so they're maintainable--who pays?
Date Thu, 09 Feb 2006 21:36:04 GMT
Dave Newton wrote:
> My question is really targeted at the politics, ethics, and 
> finances of the switch: being a refactor-early, 
> refactor-often kind of guy I'm already quite adept at the mechanics.

You'll probably still find Michael Feather's book worthwhile.  I
certainly did, even though I'd read some pre-publication excerpts.  For
dealing with the politics, I recommend the works of Gerald M. Weinberg.
> The problem is that there are probably 50 apps with 
> essentially identical (but not exactly; base code was copied 
> into an app then modified to handle specifics rather than 
> using a sub-class, interface, or other reasonable mechanisms. 
> We're talking hundreds of thousands of lines.
> "You are in a maze of twisty passages..."

<sigh/>  Duplication may not be the root of all evil, but it's close.

> > Ward Cunningham calls this situation "Design Debt."  By not keeping 
> > the code clean as you go along, you build up a balance of 
> design debt.
> >   
> Ah, good phrase: I like that.
> We have entered design bankruptcy.
> > Personally, I think it's irresponsible to hand the client a system 
> > that's wallowing in design debt.
> YES!
> Thank you!!!
> May I quote you, anonymously if you prefer?

Certainly.  And, as it's already posted on a public mailing list, it's
hardly necessary to make it anonymous.  The opinions expressed are those
of me and iDIA Computing, LLC (, not Wells

> > Who bears that cost depends on how it's presented to the 
> client.  If 
> > the estimator didn't take this situation into account when they 
> > negotiated the job with the client, it can be very difficult to 
> > convince them later.  And since they've probably already 
> dealt with a 
> > development team that delivered less than was purchased (i.e. the 
> > messy system), they'll already be predisposed to distrusting 
> > development teams.  Gaining that trust is the key, but it's 
> not easy.
> >   
> Yeah... plus my estimates for fixing the broken system aren't 
> exactly low.

I can imagine.  I think the key is to try to make progress on cleaning
up the system, without biting off more than you can chew.  Even the best
client with such a system is unlikely to find fixing everything
affordable.  The only strategy that can work, in my opinion, is to
attack the issues that cause the most problems for the enhancements that
you need to make, and wall off other areas to tackle later.  It can be
tricky to pull off.  Sometimes a "deprecation refactor" works for this:
create a new way for part of the system, and later migrate other parts
over to it.  This is a messy process, of course, and in the interim
leaves the system even a bit more confusing.  Again, this is stuff that
Michael Feathers has covered well.  You may want to check the yahoogroup
on the topic (dormant now, I believe) and other resources on the web.  I
still find the book a good reference, however.

Keep in mind that the goal is to deliver business value to the client,
while paying down the current debt.  There is no silver bullet to make
the problem go away--it takes discipline and effort.  The client
currently owns the problem.  Successful development teams rarely
propose, "If you pay us fairly for this bit of work, we'll do anything
else you need for free."  I wouldn't accept such a proposition, either.
But I would propose to work in the client's interest, and preferably in
close communication, to accomplish the client's goals in the most
economical means possible.  And "most economical" doesn't mean "quick
hack" because that quickly leads to higher costs as the code becomes
harder to work with.

 - George

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message