You and your team are working on a new version of the product. There is an strict deadline that you simply can't meet within high-quality standards, and you are not allowed to cut corners of these must-have features. After explaining the situation to your manager, she responds that this is a business decision and that you have to do whatever is necessary to meet this deadline. In other words, you need to do some low-quality work which should be reviewed and enhanced in the future.
Does this scenario sound familiar to you? This is the most common example of technical debt, but we are not just talking about unclean code that needs to be refactored. Other types of technical debt are bad design, insufficient test coverage, poor integration, etc.
Sometimes it is necessary to take on some debt for compelling reasons, such us going out of business otherwise, or being the first to market. However, the decision makers must have in mind that it is a loan after all, and it has to be repaid one day... with interests. Taking on technical debt means taking a loan today against the time required to do future work, so the greater the debt today, the slower the team's velocity tomorrow.
There is a limit, called tipping point, when the product becomes unmanageable or chaotic, and even small changes become major occasions of uncertainty. Make sure that you have repaid your debt before you arrive to this unpredictable point.
Other consequences of technical debt are frustration, underperformance, decreased customer satisfaction, rising development and support costs, etc.
The best practices to repay technical debt are:
1) Commit to do high-quality work so that we don't add new technical debt
2) Clean up whatever happened-upon technical debt that you reasonably can
3) Devote a percentage of your time (5%-33%) to specifically repay targeted technical debt
However, there are at least three scenarios under which technical debt should not be repaid: product nearing end of life, throwaway prototype and product built for a short life.
Remember: technical debt, like financial debt, has to be managed. Don't underestimate it's consequences.