A number of bloggers including yours truly have been revisiting the concept of technical debt over the past month or two, given the parallels between it and the financial kind making headlines every 10 minutes; and also the fact that projects are being reined-in across numerous organizations due to budget, economic, and headcount issues caused by difficult current economic conditions.
Martin Fowler recently posted an interesting piece about how one would go about measuring technical debt, and I'll add a few other items to consider.
One thing about technical debt that often gets overlooked is that it cannot be reasonably measured or estimated until it has been incurred - that is, after the fact. Financial debt scenarios are estimated in a more straightforward way because certain critical factors such as interest rates and payback periods are known up front, reducing the uncertainty, but not eliminating it.
Martin also mentions that measurements of technical debt are subjective because the resulting system is measured against a system in, as he put it, "an imaginary state." While this is true in a substantial number of cases, I believe that some (not all) of the subjectivity in such measurements can be mitigated if an overall design/architecture exists up front. How much design and architecture? That's also quite subjective, but such artifacts would establish a baseline that facilitate objectivity in measuring and controlling technical debt.
Then we come to the debt measurements themselves. The most straightforward metric with technical debt is time - how much time will/did it take to build/refactor assuming that the overall system was "clean?" Those estimates come in units of time as that what the project team utilizes daily and reports in standups or project meetings. However, time as a form of 'debt' usually doesn't resonate with non-technical managers - but money does. For example, I can tell a project sponsor or product owner something along the lines of Martin's example - 'if the system was 'clean,' we incurred 2 days of interest on our technical debt." While that usually gets acknowledged, the ramifications aren't clear.
What does get their attention is when that 2 days of interest is converted into monetary terms. The straightforward way of doing that is: (Cost of involved team members per day) X (Number of days of interest). For this to work, we must know how much 1 day of labor per team member (hours work also) is costing the project and multiply it by the number of team members involved. Then multiply it by the days (or hours) of interest paid. Now, we have an approximation of how much the technical debt cost in financial terms, which will definitely get management attention if its high enough (and hopefully not high enough to get the messenger shot).
Again, keep in mind that these measurements are made after the technical debt is incurred, and are rough approximations, not cold hard facts. Having a design/architecture as a baseline improves these measurements, otherwise the 'imaginary state" (or design/architecture after the fact) as Martin describes must suffice.
If anyone has better methods or optimizations on this, I'm all ears and eyes.