To be clear: I do not think we should actually forget technical debt. Also, this is not the nth post discussing if “debt” is an appropriate metaphor. I do not have a strong opinion regarding the metaphor. My point is rather that I realized in a recent discussion that in the end, it is not so much about technical debt but rather about something else, and I wanted to share the thought.
You must log in or # to comment.
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.
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.
Yes, thank you. It’s really as simple as that
A client recently approached me with the need to measure technical debt.
The writer made the whole essay because saying “just ask your engineers what they need to improve” wouldn’t make him money.
The writer made the whole essay because saying “just ask your engineers what they need to improve” wouldn’t make him money.
I wonder if the writer ever worked as an engineer.
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.
It’s not debt, let’s call it what it really is, neglect.
