#📚reference This concept is often raised when the [[maintainability]] topic is touched. Technical Debt refers to the implied cost of additional rework caused by choosing an easy, expedient solution now instead of using a better approach that would take longer. It's a metaphor coined by Ward Cunningham to illustrate the long-term consequences of quick fixes or shortcuts in software development, which incur interest payments (in the form of increased future maintenance) similar to financial debt. Just like financial debt, technical debt accumulates when developers take shortcuts or implement temporary solutions in the software development process. These shortcuts may speed up development in the short term, but they can lead to complications and increased costs in the long term, uncontrollably growing as a snowball. ![[technical debt.jpeg|600]] It can manifest in various ways: - Implementing new features or changes becomes unproportionally difficult compared with the outcome due to complex or poorly designed code. - Higher risk of bugs and software failures critical for retaining or extending client base. - Decreased ability to recognize problems on the spot due to overall code quality and readability, which may lead to a snowball effect when poor unreliable code produces more bad code and more defects. - Impossibility to fix critical issues within a reasonable time. This may include the inability to restore the system after a failure without reputation risks. - Inability to grow in response to the increased demands from users. ### How bad is it? Again, it is the same as a bank loan — it can be considered an instrument. Quick results can save you time and money (for instance, when you need to patch a critical bug on production). But just like with a loan — its settlement should be taken seriously. Otherwise, it might lead to bankruptcy. Only a deep understanding of your business can answer the question: What would be the bigger failure: not implementing a critical feature or implementing it in a way that the happy clients will crush your website? As one smart engineer said: > `Within a development, you can either RESOLVE the Tech Debt or ADD the Tech debt.` So, it should be considered unavoidable and treated wisely. ### Paying the Debts It is important to emphasize that technical debt is always something we articulate and account for. Writing bad code is just incompetence. To manage technical debt, we need to be able to express our concerns, estimate the risks, and track the shortcuts we made. This requires both a communication policy that encourages people to speak freely, technical competency from product owners, and the ability of engineers to explain the consequences of the action taken for the business goals. Management of a technical debt does not require special instruments. We identify it during code reviews or planning sessions, name it using an issue tracker, or with properly written "TODO" in the code. The most important condition of successful technical debt management is the ability to assess the outcome of creating and fixing shortcuts. The next important thing is to be consistent. If we name something a debt, it has to be paid in due time. Otherwise, we are just fooling ourselves. And this could be even more dangerous since it creates a false sense of security. Still, when the business goals are properly communicated, the product roadmap is clear for engineers, the latter are ready to fix the beautiful mess they've created, and the product team understands the risks, then working with technical debt can be even as fun as playing a game of chance. After all, any business enterprise is just a carefully calculated risk. --- <font style="color: #F86759">Contributors:</font> *[[Eugene]], [[Mykhailo]]* <font style="color: #F86759">Last edited:</font> *2024-03-27*