ROI

ROI isn't just about money, it also applies to refactoring and redesign in your code.When you refactor you need to think about what the cost is and what you get. Don't forget the risks and costs.

Risk

• Will the refactoring help
• How long will it take
• Will it introduce more bugs

Costs

• Time away from building new functionality
• Code changes others must figure out
• Time/effort to learn the refactorings necessary to implement the change

Benefits

• Future features can be implemented faster
• Patterns in your system may become clearer for others
• Bugs may be more obvious in the refactored code
• The code may become maintainable (readable)

Ask yourself: Do the benefits outweigh the costs?

In my current refactoring I'm clarifying the Snapshot pattern ala Martin Fowler in our code. We have a mixture of Snapshot patterns (delegates and facades) in the code and the business logic is spread between snapshots and their backing objects. Our ROI for this refactoring has been as follows:

Benefits

• Bugs/duplicate code around date effective logic. No separation between valid data and valid data for a date. This should clean that up.
• No clear patterns for implementing the next date effective thing, so we'll get another new one, with a different set of bugs
• More maintainable. Some of the common code for date effectiveness is being pushed up to super classes.

Costs:

• We're costing (in terms of time) more than I'd like to do this, so we'll reevaluate tommorrow
• We had to take on some extra refactorings to make this possible (ExtractSubclass to be able to move the business logic)

I believe its worth it in this case.