The time it takes to change code that is already written.
For instance, if you want feature N+1, but to do feature N+1 you need to change feature N, then the amount of time you spend changing feature N is the technical debt.
So when you are estimating, you could say: We need to refrob the whozzit to make it compatible with foo 2.0, then that work could be captured as technical debt.
One issue though: If the requirements have changed, that is not a good metrics.
i.e. We did that theme blue for Iphone, now people wants it to be green AND on windows. It's not necessarily technical debt, it's cancelling everything we've done to make something else entirely (even though it may seem superficially similar).
If the requirements and/or features for N+1 ignore or counter the requirements/features from N, it's not necessary technical debt, it might be you've just got no idea what you're coding and you're running in circle.
I think the point to take away is that software is just a tool, an artifact, and at the end of the day it just matters that it does what it is "supposed to do". However, civilization is dynamic, so we are constantly seeking to optimize an ever-changing potential function. So perhaps it is not the programmer that is running in circles, perhaps it is the market. So for the manager accounting for the technical debt, they must accept the change as a cost of doing business.
You could think of technical debt as the energy lost due to friction. It is the energy lost changing from one point to another in your domain space. Perhaps "technical friction" would be a better concept for software. However, that is even more hand-wavvy and harder to measure ;-)
* Tight coupling (this would include global variables, among many other things)
* Lack of code cohesion
* Code duplication
* Code that doesn't fail fast (e.g. weak typing).
* Variable/class/method naming that is either not sufficiently disambiguated or is wrong.
* Lack of tools to run and debug code
* Lack of test coverage
Whenever I go looking for code to clean up this is what I keep an eye out for.
I'm pretty sure that each of these could be measured empirically somehow (I've read papers to that effect for a few), but we're not quite there yet in terms of tooling, or even in agreement over what technical debt actually is. Give it 5-10 years.
But at the same time there is definitely some underlying real quantity. Different developers may not agree on every single aspect, but they'll agree about the difference between a good codebase and a bad one, and it really does take longer to make changes to the bad ones.
So what can you do?
