Technical debt quantifies the implied cost of additional software maintenance required in future because an easy, ad-hoc solution is chosen now to deliver software faster. It is a leeway that has been taken to ship things today, hoping that the time saved would bring returns in future, and the debt can be repaid. The additional maintenance work that must be performed in future to compensate for the ad-hoc decisions taken is called interest. If the interest is not paid, it accrues over time and makes it difficult to implement changes later.
Incurring technical debt is often a necessarily evil, since it helps deliver software faster. The adverse effects are caused primarily due to non-repayment of the interest and inability to implement good software development practices.
The term technical debt was coined by Ward Cunningham in 1992. Cunningham is an American software developer and is attributed for developing the first wiki software. He is considered a pioneer in design patterns and extreme programming. He has described the concept of technical debt as follows:
"Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise."
What are the causes of technical debt?
The major causes of technical debt are — lack of objective code-review processes, lack of documentation, poor estimation of product releases, not following best practices or industry standard patterns, among others.
What are the effects of technical debt?
The biggest cost of technical debt is the fact that it slows the ability to deliver future features, thus handing an opportunity cost for lost revenue. When accumulated over time, bugs would start cropping, impacting software stability and reliability. These factors also result in developer unhappiness, burnout, resulting in low productivity, thereby compounding the first two aspects.