Technical debt has become a ubiquitous metaphor in the world of software development. If you're not familiar with it, the gist is that it represents the accumulation of design errors you've made, shortcuts you've taken while trying to meet a deadline, and perhaps even the inconsistent domain language and code/architecture styles you have living side by side in your code base that slow down development, cause confusion in meetings, or make it harder to onboard new developers. Basically the sum total of everything that's wrong with your software in various ways from how you'd like it to be if you were starting over clean today to write something that did exactly the same thing. Every organization I've encountered acknowledges that it has some debt, but none of them seem to take the metaphor very seriously.

Though imperfect, I think the analogy to fiscal debt is a good one. Like fiscal debt, technical debt is not inherently bad, something to be avoided at all costs. We defer decisions and accept shortcuts both for legitimate business reasons and because we don't yet know the right abstractions to use in place of ugly but functional code, and I think that's as it should be in many cases.

Not all debt is created equal of course, but before we can consider extending the metaphor with some analogous idea to "credit ratings" for a codebase or a team, I think we need to fix the problem of debt visibility and awareness. A business having debts is to be expected, but we would be appalled if a business had no idea how much it owed or to whom, and it's no less alarming that we know so little about our technical debt and leave it an entirely subjective, unquantified, unformalized metaphor.

No two developers are likely to agree on all of the concrete details of what qualifies as technical debt or how it can be paid down; as teams and organizations though, we can at least attempt to formalize and share our thoughts. Ideally, we would do this with tools and metrics that live inside our codebase, right where the debt lives. Debt Ceiling is one such tool I've been developing, for ruby code, that features a configurable combination of automatic and manual assignment of debt, some historical perspective on that debt, and integration with test frameworks so that restrictions and goals around debt can be defined for a project and enforced by continuous integration and/or locally on developer machines in a consistent, automated fashion.

I'd like to extend Debt Ceiling to work in other languages, but it's worth mentioning that some other tools do exist; I only discovered them after starting to build my own, though the other tool, SonarQube, is only partially open source, and I have no experience using it. It does feature better language support then Debt Ceiling at the moment, so if using Java or other non-ruby languages, it might be a better fit for you at the moment.

The more important question is whether and how we, as a tech community, are ready to take the idea seriously and step up and test how well we understand our own processes and problems. Perhaps technical debt is not the best metaphor for understanding problems and past errors or short-cuts in our software development process, but as long as it's the dominant metaphor we're using, we should experiment with improving our understanding of it in practice and in theory.