What Is Technical Debt?
Understanding one of the most important tenets of software engineering.
Join the DZone community and get the full member experience.Join For Free
The term technical debt was coined by Ward Cunningham in 1992. To understand technical debt, let's compare it with financial debt.
Financial debt is an arrangement that gives the borrowing party permission to borrow money under the condition that it is to be paid back at a later date, usually with interest. Financial debt is generally needed due to overspending, lack of financial knowledge, poorly managed budget, etc. to name a few. You might also raise a financial debt to invest in your capital-intensive business, education, etc. which would bring returns in the future. Financial debt is not always a bad thing as long as you're aware of the consequences and always keep it under control.
Now assume a scenario in software development - there are constraints placed on the development of a product, primarily in terms of the delivery deadline, or a business decision has been made with a lack of technical implementation knowledge. An ad-hoc decision would need to be made intentionally to meet the delivery deadline. This results in technical debt. It is a leeway that has been taken to ship things today, hoping it would bring returns in the future. But the "interest" must be paid - the ad-hoc decisions are taken today must be corrected sometime in the future.
Causes and Effects
The major contributors to technical debt, however, are the unintentional and caused by non-repayment of the interest - lack of objective code-review processes, poor estimation of product releases, not following best practices, or industry-standard patterns, to name a few. Inadvertently, without being aware of the butterfly effect it causes, people move on to the next thing. Like financial debt, the technical debt incurs interest, in the form of the extra effort that we have to do in future development because of the quick and dirty design choices made. In technical debt, refactoring is like repaying principal, and slower development due to complexity is like paying interest. As long as you're well aware of the choices you've made and try to repay the debt on time before moving on, it is not a bad thing.
The biggest cost of technical debt is the fact that it slows your ability to deliver future features, thus handing you an opportunity cost for lost revenue. When accumulated over time, bugs would start cropping up tossing software stability and reliability. These factors also result in developer unhappiness, burnout, resulting in low productivity, thereby compounding the first two aspects. The tricky thing about technical debt is that unlike money it's hard to measure effectively. To take action on technical debt, one should have absolute visibility of the current state of their code.
Published at DZone with permission of Jai Pradeesh. See the original article here.
Opinions expressed by DZone contributors are their own.