Staying on Top of Your Technical Debt
- Technical debt is defined as the cost of additional work that you’ll have to perform tomorrow when you choose to go the easy way today;
- Just like financial debt, tech debt can have a positive business impact;
- However, accumulating too much technical debt can have adverse consequences — like any debt, it eventually needs to be repaid.
As businesses and institutions worldwide were suddenly faced with the need to digitalize their process and models overnight, they had to choose practicality and speed over thoroughness and comprehensiveness in order to keep serving their customers or constituents.
But what of the “remaining to do”? When should an organization repay its technical debt, and what happens if it never does?
Understanding Technical Debt and Its Causes
Technical debt (which is also referred to as design debt or code debt) is a software development concept that describes the development work that gets delayed in order to meet a deadline or requirement. Like many other software development terms and notions, it is also applied to other industries and lines of activity. In other words, this is the work you will have to put in tomorrow because you chose to take a shortcut today.
- Some of the most common causes for technical debt include:
- Lack of skilled human resources
- Business imperatives and pressures (including the need to deliver a product or software to market as soon as possible)
- Lack of upfront definition of requirements, resulting in last minute changes in specifications
- Lack of technology vision or leadership
- Elongated projects or development cycles that are therefore subject to obsolescence
- Development work that’s made in silos or in isolation and that requires extra consolidation work as a result
An important feature of technical debt is its cumulative nature. Poorly designed systems tend to require more maintenance work. Besides, any change you’ll have to make in the future will require making other related adjustments to preserve the system’s consistency and internal coherence — we may call this “technical interest”.
Good Debt vs Bad Debt
Ward Cunningham, the developer who coined the technical debt metaphor (and who incidentally co-wrote the Agile manifesto), explains the parallel in a video:
From this perspective, we understand that, just like financial debt, technical debt is not necessarily a problem. A reasonable amount of technical debt can actually be a business booster. Building minimum viable products or proofs-of-concept can be viewed as best practices, and it may make sense from a business point of view to accept a few minor flaws in order to release your software or products sooner.
So, borrowing future work can have its share of advantages and benefits. But what will happen on reckoning day?
What if You Default on Your Technical Debt?
What of organizations that accrue significant technical debt and find it hard to pay it back? Is it possible to write it off and never repay the tech debt? Although it is theoretically an option, procrastination may eventually become even more expensive.
Just like in architecture, delaying repairs can eventually lead to an unmaintainable structure —and, in the worst cases, to outright collapse.
Poorly designed and maintained systems and software are putting extra strains on human resources, reducing productivity and generating stress. Old half-baked code eventually becomes too confusing to understand and to fix, making the whole software virtually unusable. And users suffer from it.
Hence the importance of keeping track of your technical debt in order to be able to manage it properly. Unlike financial debt, which can be categorized, broken down, analyzed and displayed on spreadsheets, technical debt is much harder to monitor and to understand unless technology leaders actively track it and decide beforehand how much tech debt is too much.