[EMAIL PROTECTED] wrote: > 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. > 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.
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..." > 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? > 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. *sigh* Dave --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
