What is technical debt?
The term technical debt was coined by Ward Cunningham in 1992. To understand technical debt, let’s compare it with financial debt.
A financial debt is an arrangement which 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 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 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 future. But the "interest" must be paid — the ad-hoc decisions are taken today must be corrected sometime in the future.
Technical Debt 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, 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 of technical debt 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.
DeepSource’s vision is to educate teams with industry-standard practices and patterns, and provide actionable insights on code continuously. Though our tools automate parts of these workflows, we firmly believe in educating developers and team managers along the way in form of articles about ways to keep technical debt under control, reduce the existing debt and avoid it as much as possible in the future.
