An Approximate Measure of Technical Debt
James Shore has an interesting take of measuring technical debt:
Measuring Technical Debt
I’ve been searching for a measure of technical debt (or its inverse, design quality) to help address this problem. Now, no measure is going to turn bad programmers into good programmers. Design quality is a human problem, and compilers eat spaghetti code just as easily as they eat clean code. But I think it would help if people could at least tell when they were making things worse. Unfortunately, traditional measures such as McCabe’s cyclomatic complexitydon’t do a great job of exposing the large-scale technical debt I see most often.
I think I’ve finally found the right metric. It’s a good one. Years of research has shown that this metric correlates closely with cost, effort, and bugs. I’m surprised nobody thought of it before now.
Read his ideas here: James Shore: An Approximate Measure of Technical Debt.