TechnicalDebt

You have a piece of functionality that you need to add to yoursystem. You see two ways to do it, one is quick to do but is messy -you are sure that it will make further changes harder in the future.The other results in a cleaner design, but will take longer to put inplace.
Technical Debt is a wonderful metaphor developed by WardCunningham to help us think about this problem. In this metaphor,doing things the quick and dirty way sets us up with a technical debt,which is similar to a financial debt. Like a financial debt, thetechnical debt incurs interest payments, which come in the form of theextra effort that we have to do in future development because of thequick and dirty design choice. We can choose to continue paying theinterest, or we can pay down the principal by refactoring the quickand dirty design into the better design. Although it costs to pay downthe principal, we gain by reduced interest payments in the future.

The metaphor also explains why it may be sensible to do the quickand dirty approach. Just as a business incurs some debt to takeadvantage of a market opportunity developers may incur technical debtto hit an important deadline. The all too common problem is thatdevelopment organizations let their debt get out of control and spendmost of their future development effort paying crippling interestpayments.

The tricky thing about technical debt, of course, is that unlikemoney it's impossible to measure effectively. The interest paymentshurt a team's productivity, but since weCannotMeasureProductivity, we can't really see the trueeffect of our technical debt.
One thing that is easily missed is that you only make money onyour loan by delivering. Following theDesignStaminaHypothesis, you need to deliver before youreach the design payoff line to give you any chance of making a gainon your debt. Even below the line you have to trade-off the value youget from early delivery against the interest payments and principalpay-down that you'll incur.