they asked me if I could develop some useful metrics for technical debt which could be surveyed relatively easily, ideally automatically

This is where I would have said “no, that’s not possible” or had a discussion about risks where things you simply can’t cover with automated metrics would lead to misdirection and possibly negative instead of positive consequences.

They then explore what technical debt is and notice that even many things outside of technical debt have significant impact you can’t ignore. I’m quite disappointed they don’t come back to their metrics task at all. How did they finish their task? Did they communicate and discuss all these broader concepts instead of implementing metrics?

There’s some metrics you can implement on code. Test coverage, complexity by various metrics, function body length, etc. But they only ever cover small aspects of technical debt. Consequently, they can’t be a foundation for (continuously) steering debt payment efforts for most positive effects.

I know my projects and can make a list of things and efforts and impacts and we can prioritize those. But I find the idea of (automated) metrics entirely inappropriate for observing or steering technical debt.

Technical debt is a management term.

The reason we use it is to tell non-technical management people why implementing a simple feature might take an hour on a fresh project and a week on an old legacy project.

It’s used to tell them why we shouldn’t go with the quickest and dirtiest solution but instead should go with a more expensive proper solution.

It also tells management why we might have to spend some time imrpoving our code base without any tangible improvements to the customer.

And because it’s a term that speaks to non-technical management it uses financial language, becausee that’s what they understand. Technical debt means “I am choosing to cut corners today, but we will have to pay up in the future by fixing stuff that wouldn’t be broken if we do it right today.”

And because it’s aimed towards non-technical management and not towards developers, it’s of course not very specific. Non-technical management doesn’t need to understand about dependency hell, unclean code or bad developer documentation. That’s not their field and it doesn’t have to be.

The real problem in OOPs example wasn’t that there’s no clear metric or definition of technical debt. The problem was that non-technical managemnt thought that technical debt is an engineering concept instead of a management one, and thought that they themselves were allowed to meddle with it.

The right way to handle that is to ask the people who are actually impacted by technical debt what they want to improve. Any developer can quickly give you a good list of the most pressing tech debt issues in their code base. No need to pull in someone from outside of the project to make up some useless KPIs that will end up missing critical topics.

Btw, engineers already have engineering terms for what’s described as technical debt. E.g. “dependency hell”, “low test coverage”, “outdated dependency”, “bad code style”, “unoptimized code” and so on. And since these are engineering terms, they actually have specific meanings and most of them are testable and quantifiable in some specific way.

I think this was a good piece of writing and states quite well the reasons why I don’t like technical debt as a term. Especially in situations where people say it’s necessary.

In my opinion the root cause is poor management and poor management is not necessary.

It’s not debt, let’s call it what it really is, neglect.