January 2, 2021
The analogy of “debt” has become pervasive in software teams, and while it may be useful when trying to communicate with business stakeholders about the risks an engineering team might be incurring, I’m going to make the case that engineering teams should not create and dedicate time to a “tech debt” workstream. Specifically, I think there are two reasons why creating a “tech debt” workstream doesn’t help a team make forward progress.
The first problem with a “tech debt” workstream is that it is frequently decontextualized.
Software systems exist to serve a purpose, and we make changes to software systems so that they may better serve that purpose. Similarly, organizations have goals, and then there are problems that interfere with our ability to accomplish those goals. If the goal ceases to exist, is the problem still a problem? Consider:
- A business might need to work with a variety of shipping logistics partners, and has integrated with them by adding a bunch of switch statements in a variety of places in their codebase. Adding a new partner becomes a painful process due to the number of code touchpoints that need to be carefully updated.
This code may cause discomfort due to its aesthetics (and will probably get dumped into a “tech debt” backlog as a result), but whether or not it’s a problem for the business depends on how many more partners the business needs to integrate with and how much change is going to take place in the integration code.
Tech Debt backlogs will have this tendency to accumulate tasks decontextualized from specific problems, and as a result, even with concerted effort to burn it down - it will frequently not feel particularly meaningful or impactful.
Not having this style of backlog doesn’t mean that maintenance work is never performed, but rather that a team would ideally have a clear understanding of its long-term objectives, and how maintenance-type work will or won’t meaningfully affect bottlenecks and obstacles towards achieving those objectives.
Leverage Points 🔗︎
The second problem with a “tech debt” workstream is that it encourages you to think primarily of the analogy of “paying down” debt as the solution. If there’s too much debt, then you need more capacity to pay it down. Donella Meadows would probably consider this to be the following Leverage Point:
- Constants, parameters, numbers (such as subsidies, taxes, standards).
She considers this to be the least effective Leverage Point, and anecdotally, I’ve basically never seen this succeed. If you consider a variety of problems that people would describe as technical debt: upgrading extremely old framework versions, concepts that have aged and degraded beyond all recognizability, features whose implementations made it nearly impossible to make further changes, etc. - each of these problems generally has root causes that are not resolved by “paying down the debt”.
Consider two Leverage Points that Meadows views highly:
- The goals of the system. - The mindset or paradigm out of which the system — its goals, structure, rules, delays, parameters — arises.
If you find yourself in a situation where features are constantly being hacked together in order to hit dates set by the sales organization, what will “paying down the debt” accomplish? Does having a “tech debt” workstream actually contribute to having a healthy long-term system?
Instead of throwing capacity after a target that will always move away from you, a whole-system perspective (encompassing people, processes, and technology) and the use of more powerful Leverage Points might actually result in better long-term objective attainment.