Measuring Technical Debt

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.

Comments

[Kurt Häusler]

"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."

That's true for legacy code, but I think for new code, written by a team aware of technical debt, technical debt should only be incurred on purpose.

We should always ask why technical debt was incurred, for legacy code the answer is usually "because we didn't know any better", but once a team is aware of technical debt, everything changes. You should always be able to go back and assume that technical debt was incurred for some reason, and that before someone made the decision to incur it, they were able to estimate the size of it.

(Incidentally I am a fan of measuring TD in story points if you already work in a system that uses stories and story points; the interest is included in the stories that are made more expensive by the TD, paying back the principal is a separate story)

Traditionally software quality management has always had to rely on "after the fact" measurements, such as testing and bug-fixing and I think technical debt management represents a possible avenue into "before-the-fact" software quality management.

[Debt Help]

Hey, nice job on the blog here. Some good ideas. Keep up the good work.

[Keith]

disagree with some points but overall good article. thanks!