# Technical Debt Technical debt is about quality issues that appear when software is not maintained properly and when pragmatic (or stupid) choices are made that lower the overall quality and create issues that will need to be solved at some point in the future, potentially with a much higher cost. Usually means that decisions were made for expediency that have a higher long-term cost than an alternative that had a higher short-term cost. Technical debt fundamentally it means that you borrowed (hence: debt) time/efforts from the project's future to support its present. It isn't always the result of bad choices. Sometimes they're the result of pragmatic choices, fully knowing the consequences. In those cases they're only bad when you don't pay them off when the time comes. When considering a software project, technical debt can appear everywhere: - Infrastructure maintenance (e.g., using new Web server versions, migrating Kubernetes configuration, updating Gitlab CI or GitHub actions code to comply with new rules, etc) - Build tooling maintenance (e.g., updating NodeJS, npm, yarn, TypeScript, Webpack and other build tools, etc) * Dependency management (e.g., updating all libraries to supported/safer versions) * Software architecture (e.g., not properly architecting a system or a part of it) * Software design (i.e., not taking time to properly design new features) * Code quality in general * Testing (i.e., not writing tests for new or changed features) * UX design * UI design But elements outside of the system itself can also suffer from technical debt: team organization, project management, marketing, sales, etc. Related to the [[Broken windows theory]]. The [[Boy Scout rule]] can help keep technical debt low. ## References - https://martinfowler.com/bliki/TechnicalDebtQuadrant.html