Technical debt is one of those concepts that has both gained a lot of traction over the last few years, and in some ways been misused as a concept quite heavily. It seems that nearly anything and everything that people don't like about a code base gets lumped into a broad technical debt category, so it's getting harder for people to define with clarity what technical debt actually is as the concept becomes more and more muddied but people's perceptions as to what it is they are looking at when they perceive technical debt. Contributing to this lack of clarity is the need to be able to quantify this debt, and to measure it in a meaningful way. The problem is however, that technical debt isn't like bank loan, where you accrue a fixed amount of debt and you pay it of bit by bit, and I can't help but think that for many, the definition of the word Debt has left many feeling that it is something very specific. For others, the issue is that everything they do incurs a measure of "debt" that negatively impacts on the product, so there is a kind of underlying hysteria that leads some people to believe that they need to measure every little thing about their software development, and that somehow they can see a report that will pinpoint where the problems lie. The reality however is both much more subtle, and perhaps much simpler than many people are leading themselves to believe.
