In between developers a fairly reliable measure of technical debt seem to be WTFs/minute.
Issue with this "metric" is that it is typically rather difficult to communicate "outside".
Metric that worked for me in communicating technical debt to "outsiders" was amount of testing and bug fixing effort (especially for fixing regression bugs) needed for successful delivery.
A word of caution: although this approach is quite powerful, one would better double-check with good old WTFs/minute before resorting to it. Thing is, it is quite cumbersome: to get the data, one has to carefully track time and accurately log it per appropriate categories.
- it is so much easier to state 3 weeks total spent on implementing feature A than
I spent 14 hours on draft implementation of feature A then 29 hours on smoke testing it then 11 hours on implementing fixes for regressions I discovered, then 18 hours testing the QA-ready feature implementation. After that, QA guys spent 17 hours on testing the initial candidate release. After that I spent 13 hours analyzing bugs submitted by QA for the initial candidate release and 3 hours implementing the fixes. After that, I spent 11 hours on smoke testing the changes I made to initial candidate release. After that...
Anyway data about testing and bug fixing effort has been quite easy to communicate in my experience.
For recent release, we spent about 90% time on testing and fixing regression bugs. For next release, suggest to allocate some effort on getting this value down to 60-70%.
Another word of caution. Data like 90% above could be interpreted not only as an indication of technical debt, but also (surprise surprise) as indication of one being not quite proficient in programming / particular technology. "You just make too much bugs in your code".
If there is a risk of data being misinterpreted that way, it helps to have an additional, reference data on something less WTF prone to compare against.
- Say if there are two similar components / applications maintained by same developer(s), first releasing at "waste rate" about 50% and second at 80-90, this makes a pretty strong case in favor of second being subject of technical debt.
If there are dedicated testers in the project, they could also contribute to more objective evaluation of the data. As I mentioned in another answer,
With testers, you get someone to backup your understanding of design issues. When there are only developers complaining about code quality, this often sounds like subjective WTFs from behind the closed door.
But when this is echoed by QA guy saying something like
component A had 100 regression bugs for 10 new features, as opposed to
component B which had 10 regression bugs per 20 new features, communication suddenly turns into whole another game.