Debt isn't always a bad thing... unless you let the debt build up and grow over time!

Your decisions should be based on what is best for the business. For example, consider these common scenarios:

Quick Fix

You discover that a UI isn't as intuitive as first thought. Some functionality is not obvious to the users. The UI designers have two approaches to consider:

1. A fairly substantial redesign that will take at least two weeks
2. Quick fix: Add some static text labels, and add some fade-in flyover-type balloons to point out the unclear elements. This will take a few hours. Chances are that some of the flyover tool-tip style notes will still be useful in the new redesign.
   

So, the business can then decide to do the Quick Fix (#2). That is, spend a bit of money on making the existing UI more tolerable and get the fix into the next iteration/release. The longer-term fix can then be scheduled as needed.

There is nothing wring with incurring TD as long as you do so "eyes wide open" -- that is, after analyzing the options, and you have a path to paying off the debt as soon as possible.

Writing and Rewriting

Another scenario involves "stumbling upon" the best solution through trial and error. Despite your best efforts at determining best design ideas up front, sometimes the best arbiter of which approach works best is simply to do the implementation the best way you think, and learn from it. (Okay, that sentence had a lot of "bests!")

Instead of spending inordinate amount of time in analysis mode seeking the optimum solution, get something written that works and meets the business needs. Then consider putting in a refactoring task to refine the solution based on what you have learned.

Scrap It and Start Over

For new products, the feature growth in the first 5 years may be so rapid that you should completely redesign/refactor the application architecture every 18 months, or so. That is, given all that you have learned, you would now design the system in a different way. Instead of choosing to refactor a substantial amount of the code -- which can be quite difficult as you must refactor all of the tests as well -- you simply opt to design the system from the ground up. This is especially useful when you find that you are facing an arduous task to add in some substantial new functionality. When it seems as though you really have to work way too hard to add in the new functionality, and it just doesn't "feel right," this is when you should consider the "Start Over" approach.

The values behind this approach are:

• You are always dealing with a fresh and crisp code base that allows you to develop new features in an efficient manner.
  
• You do not have to try and make major refactoring efforts on the living code base.
  
• You can continue maintenance and enhancements of the existing code base.
  
• You can leverage the most important parts of reuse: understanding the requirements and how it was built.
• It can be very cost-effective due to writing logical, tight, freshly-designed code
• It is more fun for developers to work on new code designs
  

If you combine this with a "feature usage tracking" capability, you can even decide if some features should be dropped. No sense adding unused features into the new design.