It doesn't seem possible to track percentage of code as debt. You can't put a comment on code and call this block either debt or good.
One way could be to measure different activities. If you spend time solving a lot of bugs (muda) then where are those bugs?
If they're in the same old code, does that code need rewritten? If they're in new code, is that code being written in a good way? Can better testing catch these?
"Technical debt" seems as hard to measure as developer productivity. It seems you need something you can actually put on a bar chart to measure the effects of having technical debt.
You need a way to assign technical debt to a process or practice, then you can evaluate the cost of that process over time.
Could be something like... Our team spent 500 hours fixing bugs introduced during overtime, and we spent 250 hours of overtime to introduce those bugs in the first place. So an additional hour of overtime will likely introduce 2 hours of technical debt.
Or maybe... Code written using inheritance hierarchies creates 40 minutes of muda per hour, but using composition only creates 20 minutes. Or... every hour spent on throw-away prototypes reduces muda by 2 hours.
And all projects are comparable among each other, standardized for it to be possible to come up with measurements like that?
It feels like nightmare to have to come up with those hours or measure them in some way.
Anything else besides intuitive guesses by engineers won't work, because to have it any accurate at all would require perfect time tracking and understanding of all the nuances or it will just be a biased metric, which can be whatever you want it to be.
Like, the things you are spending your time on are never clear, there are never clear labels or patterns and the things you spend most time in the future can be very unexpected, the more so, the larger the org.
It doesn't seem possible to track percentage of code as debt. You can't put a comment on code and call this block either debt or good.
One way could be to measure different activities. If you spend time solving a lot of bugs (muda) then where are those bugs?
If they're in the same old code, does that code need rewritten? If they're in new code, is that code being written in a good way? Can better testing catch these?
"Technical debt" seems as hard to measure as developer productivity. It seems you need something you can actually put on a bar chart to measure the effects of having technical debt.