Technical debt as a metaphor is an incredibly valuable communication medium. It’s supposed to fit non-functional changes into the business model.
It’s such a powerful meme that it’s taken off and evolved to the point where we are having discussions about accidental vs strategic debt , or how we should avoid it or leverage it
It’s gotten too much attention from programmers so that it has become a pretentious word for maintenance. For everyone else, it’s become a tool to make excuses for pet projects.
Maintainence
Maintenance is in the eye of the beholder. You set up a maintenance budget, and it’s the first thing that is corrupted by stakeholders.
- Refactoring a product to add a bunch of features can be interpreted as maintenance
- Replacing an existing system with AI is part of a deprecation cycle and, therefore, maintenance
- Implementing a new authentication framework to remove security risks
These can arguably take precedence over
- Upgrading infrastructure
- Writing documentation
- Patching vulnerabilities
- automating recurring tasks
- Making logging consistent
We’ve started to talk about technical debt like a target because it’s often convenient to put stuff on the roadmap under the guise of reducing technical debt. In reality, work has different goals and pushed by different interests. Using technical debt as a goal hides the underlying interests.
Types of work goals
The reality is that all the work chucked to tech debt has different goals, and treating the work as the same makes it impossible to evaluate whether the goals were achieved or not. Fundamentally, any work has 3 goals.
- Increase Revenue
- Reduce Costs
- Manage Risk
Increase Revenue 📈
Simply put, any work that will contribute to the bottom line by attracting more business, expanding the market, or preventing revenue loss. This can include features, but also solving long-standing issues that hurt paying customers. If it comes from sales, line goes up. This goal is often smuggled into technical debt work and causes scope creep.
Reduce Costs 📊
This can be directly related to the costs of tools, suppliers, and hosting, but also reducing the cost of delivery by increasing velocity. If you can deprecate a whole internal tool, scale down hosting or half your turnaround time, this is cost reduction. This is often marked as technical debt als high-cost practices are applied to achieve a quick TTM, the results are cleaned up as expected technical debt.
Manage risks ⚠️
Sometimes work is done not for the bottom line, but to make sure we have a job in the morning. Usually this means preventing production defects and outages, increased testing, security vulnerabilities, but it’s also about future proofing. If you don’t keep up with your stack, you run the risk of unforseen work in the future. This is what most engineers feel strongly about, because risk is often not taken into account into the bottom line, this goals is the most difficult to
Stop talking debt, start talking risk.
In the general zeitgeist technical debt can live anywhere outside of Increase revenue. In practice technical debt has become work that has to be done, but never evaluated, because the goal is to do it. This is not only bad because revenue increasing work is smuggled into tech debt but never held accountable for results, but it’s also a trap where many engineering pet-projects are never evaluated on impact. This is also where bugfixes turn into unaccountable features.
WTF are you doing?
Before accepting any unit of work, define ahead of time:
- which of the 3 goals it’s related to
- how it will achieve them
- quantify the expected result
If this is impossible, wtf are you doing?
After the work is done, evaluate if the expected goals were reached and hold the initiator accountable.
