Dave Newton asked: > > Assume a large body of existing work used across multiple websites: > - No documentation > - Buggy home-grown libraries (DB, connection pooling, > strings, everything) > - Home-grown "custom tag" system (parse the file on each page load) > - Essentially un-maintainable and un-extensible > > So... How do you deal with this situation?
I recommend the book Working Effectively with Legacy Code, by Michael Feathers. And the book Refactoring, by Martin Fowler. These two will sharpen your tools for working on this system. They'll also help you concentrate on what you need to clean up for the work you're doing, and leave aside cleaning up other parts until it's necessary. > It takes too long to work on the existing codebase (I'd > guesstimate a minimum 2-4x longer than a reasonable > implementation, plus immeasurable developer irritation & > frustration) for even the most minor of changes. Can you > legitimately bill clients for work that should have already > been done? Do you have to justify to every client the extra > hours put in because of the current state of the app? _Can_ > it be justified? Does it have to be an internal cost, and if > so how can you generate momentum to get it done? 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. Every thing you do becomes a little harder to do. This is like paying interest on the debt. For short periods, this can be a reasonable tradeoff, but many teams only make the minimum payment, letting the mess, and resultant difficulty, grow over time. Personally, I think it's irresponsible to hand the client a system that's wallowing in design debt. And many clients are not able to judge this for themselves (as they might look at the balance carried on a credit card). Whether they paid less for the messy system than they might have for a clean one is a moot point, after the fact. (And generally I think the answer is "no.") The face is that they own a system that's going to be harder, and therefore more expensive, to maintain. 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. - George http://www.idiacomputing.com/moin/FavoriteBooks --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
