Technical Debt

This wonderful metaphor by Ward Cunningham reminds us that doing things in a “quick and dirty” manner or taking shortcuts sets us for a debt which, when not repaid promptly, incurs interest in the future.
When developing systems, enhancing existing ones, or even fixing bugs, we will typically arrive at a crossroad: should we take the time to do it right; or should we take shortcuts and deliver quickly?
It is generally in the interest of the business folks to roll out changes quickly; while the development folks would choose to properly design, implement and test changes before delivery.
Fortunately, It doesn’t apply to everything (e.g. code smells or design flaw). 
It requires a deliberated decision to do something that is not sustainable in the long-term, but yields a short-term benefit. The result of which is not in the interest of the system's ongoing maintainability.
 

Examples of technical debt

Some common examples include:

1. hardcoding values in source code
2. postponement of documentation
3. postponement of writing tests
4. overusing TODO comments
5. ignoring compilation (e.g. deprecation) or code analysis warnings
6. not merging code in source code management

Issues with technical debt

How does a technical debt haunt us? The following could be signs of debt (or interest, in financial terms):

1. instability in the system
2. increase maintenance costs
3. feeble architecture affecting extensibility
4. patching data takes up most of the time

Should one ever incur a technical debt?

Indeed, there is no right or wrong!
The recommendation is that:

• if the system is reasonably stable, incurring a technical debt is fine. However, this needs to be repaid promptly.
• if the system is nowhere stable, do not incur further debts. The reason for the current state may well be due to a technical debt!?

How does one pay down the debt?

A common excuse to paying down technical debt is "if it ain't broken; don't fix it".
However, the recommended 3-pronged approach is:

1. Track down the technical debt
2. Stop incurring debt
3. Start repayment

Repayment which could be in these forms:

1. go back to make changes one would have done if time and resources had permitted
2. tune the system (oil the machinery!)
1. database tuning is the most common (e.g. archiving, indexing, implement partitioning, etc.)
2. review configurable parameters (maximum requests, timeout, etc.)

Ideally, channel all resource into paying down the technical debt instead of building new features.
A more practical approach is to always reserve time to repay debts while continuing with business-as-usual (enhancements, bug-fixing, etc.).