On tech debt

Recently, I have been considering the term “tech debt” — what it means, how it is used, and the value it holds.

I have concluded that the term is too vague to be useful in formulating an argument and should be avoided. Ask 100 different people what tech debt is, and you will get 100 different answers. Use the term, and someone will inevitably apply their personal definition and biases.

When trying to persuade high-level stakeholders, arguments need to be concise; otherwise, they will be ignored. Vague hand-waving about tech debt is not persuasive. If you bring such imprecise arguments to a high-level meeting, you risk being dismissed, undermining your credibility and standing.

Arguments that align with each stakeholder’s personal goals are far more persuasive.

Instead of using the term, I plan to dig deeper into my vague feelings of unease about a particular piece of code or system in the future.

For example, I might describe the codebase as overly complicated and difficult to understand. This creates several risks: we may struggle to deliver new features in a timely manner, face a business continuity issue if a key developer leaves, and waste significant time on debugging and on-boarding new developers due to the complexity.

On a related note, I have also been preparing a dictionary of powerful language to effectively describe vague technical problems.