Monetizing the Technical Debt

by Vikas Hazrati on Mar 30, 2010 |

Most Agile teams recognize the evils associated with technical debt. Just like a financial debt, the technical debt incurs interest payments. These are paid in the form of extra effort required to maintain and enhance the software which has either decayed or is built on a shaky foundation. Most Agilists recommend repaying the technical debt as early as possible. However, most Agile teams fail to monetize the technical debt, which can give valuable insights.

Once there is a monetary amount associated with the technical debt, it helps in answering various complex and tricky questions about the software. Israel Gat suggested that unless there is a quantifiable tab on the technical debt, teams generally ignore it to a level where the software decays beyond repair.

Beyond a certain level of debt, no good option is available. The code decayed to the point in which fixing anything in a hazardous proposition – every fix is likely to break something else.

He mentioned that there is a need to monetize technical debt and represent that as a liability on the balance sheet.

According to Israel, there are multiple benefits of monetizing the technical debt.

It tells the teams when to stop developing and start refactoring - When the technical debt reaches a certain level (say 25 cents per line of code), new functionality is put on hold. The team gets into refactoring mode and no functionality is added until the debt is brought down.
Customers of the software get an idea of how risky the software is – Israel suggested that this is inline with the Agile Manifesto “Customer collaboration over contract negotiations”.
Makes investment decisions easy for Venture Capitalist – VC's can determine the rationale for making an investment in a software product.
Determines the affordability of the software – Helps answer the questions about affordability of the development and maintenance of the software as it evolves through the software lifecycle.
Helps in making the refactor versus rewrite decision – Associating technical debt with other important factors helps in making a decision to start afresh.
Helps in defining credit limits – Once monetary credit limits have been defined, they help all stakeholders including the CxO's to take informed decisions.

So what is the suggested way to monetize technical debt?

One of the ways is to use the technical debt plugin for Sonar. A technical debt analysis of a vast number of projects already is available on the Sonar live site. The cost is calculated by first figuring out the debt which is

Debt(in man days) = {cost_to_fix_duplications + cost_to_fix_violations + cost_to_comment_public_API + cost_to_fix_uncovered_complexity + cost_to_bring_complexity_below_threshold + cost_to_cut_cycles_at_package_level}

There is a default cost in hour associated with each of the above violation. For example

cost_to_fix_duplications = {cost_to_fix_one_block * duplicated_block}

Now, as per the defaults cost_to_fix_one_block = 2 hours. Assuming that the average developer cost is $500 per day and there are 8 hours to a day then to fix one such block $125 would be spent. Likewise, monetary analysis can be done for each violation to finally arrive at the total technical debt.

Thus, monetizing the technical debt gives a deep understanding of the hidden costs associated with the software. It is key for all Agile teams to keep monitoring their technical debt costs and keep them within the credit limits. Doing this helps in creating a product which is not only easy to maintain and enhance but also allows VC's to invest and customers to buy with confidence.

Related Editorial

Agile workshops and training

Speed Matters: See why Nike, Groupon, and Comcast are using New Relic

Five Key Practices to Agile ALM

Enterprise-class API Patterns for Cloud & Mobile

Agile Maturity Model Applied to Building and Releasing Software

Related Sponsor

Agile Project Management That Adapts With You. Provide your global development team a shared space that adapts to the way they work.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Community comments

I would like to see more on the topic of interest by Graham Brooks Posted

Too simple by Alexandre Poitras Posted

Re: Too simple by Vikas Hazrati Posted

Re: Too simple by Israel Gat Posted

Re: Too simple by Alexandre Poitras Posted

Re: Too simple by Israel Gat Posted

How do you trust the asset underlying the tech debt calculation? by Andrew T Posted

Re: How do you trust the asset underlying the tech debt calculation? by Israel Gat Posted

This model uses the "cost accounting" fallacy by Jason Felice Posted

Niave theory piece. by Chris Matts Posted

I would like to see more on the topic of interest by Graham Brooks

In general I agree with the approach of quantifying the current anticipated costs of resolving the different types of technical debt (Martin Fowler: Technical Debt Quadrant) but there is also interest that needs to be paid incurred as increased costs to developing features. The size of the of the debt is likely to change over time - more code built on the code with debt making the final repayment larger.

Too simple by Alexandre Poitras

I find this method not going far enough. A big bag of points representing the technical debt is nice to know approximately the amount of debt incurred on the project but from there you can't do a lot.

I prefer to have a much more detailed picture. Usually, I keep track of all the "debt" items (for instance, slow build, using an old framework version, ...) and for each one of them I have the following informations :

why you contracted the debt in the first place : was it a conscious decision or not, how to avoid it the next time, ...

what are the risk and penalties associated to this specific item and therefore what is the reward to fix it : loosing one hour per day because of the build for instance

is there a specific vision on how to fix this in the long term or not (maybe it's good enough and we won't have time to fix it). I put this item since fixing a technical issue is most of the time an ongoing process over more than a sprint unless the item is very simple.

Re: Too simple by Vikas Hazrati

> A big bag of points representing the technical debt is nice to know approximately the amount of debt incurred on the project but from there you can't do a lot.

I kind of agree but then there is a need to identify the hotspots, define the credit limit and if we have a benchmark then it is easy to compare one project to the other in relation to the technical debt.
Once we have the numbers then it is easy to drill down to the root causes on the basis of violations taking the high $$$ ones first.

Re: Too simple by Israel Gat

Please think of technical debt in the context of various personas/use cases. For a VC, the $$ amount to be "paid back" at a certain point in time might be all he/she needs. For the CEO, governing the software development process on an on-going basis (using multiple technical debt assessments) is a typical need. A CTO might be primarily interested in the Cohesion and Coupling metrics. A project leader might want to take a deep dive on the Design metric.

The state of the art these days enables us to give each technical/managerial level the most appropriate data. One can get as little of as much data as one desires.

In collaboration with my colleagues, I have carried out Technical Debt Assessments for the Cutter Consortium (www.cutter.com/index.html). We were able in these engagements to simultaneously satisfy the needs of quite a few levels.

Best,

Israel

Re: Too simple by Alexandre Poitras

Well if a manager takes a decision based on a metric rather then listening to the advice of people he trust, I'm not sure is a good manager. I mean either get your hands dirty to measure the debt by yourself or trust the people that can give you the information. Managing by metrics is a sure way to disaster in my mind. I mean it's not that I am against all metrics but I see them more as a warning signal of a potential problem rather than as a decision tool.

Re: Too simple by Israel Gat

A good manager indeed does both - "listens" to the metrics and to the team. In other words, a good manager combines quantitative data with qualitative data.

Moreover, the team itself makes use of the metrics. I have seen eyes lit when metrics provided insights to the team.

Israel

How do you trust the asset underlying the tech debt calculation? by Andrew T

Similar to how gold and trust underpin the US dollar (if you'll bear with me on this analogy), how do you determine if the "cost_to_comment_public_API" is worth including in the debt calculation? In other words, I (as a business analyst) am inclined to lean on the technical team to determine these factors. The next step would be to work with Product Managers, executives, or whomever to build their understanding of the metric and get their decision feedback based on the numbers.

Would you agree/disagree?

Re: How do you trust the asset underlying the tech debt calculation? by Israel Gat

What we usually do in Cutter Consortium (www.cutter.com/index.html) Technical Debt Assessment engagements is provide a pie chart of the composition of the technical debt to our clients. A typical pie chart might look something like the following:

Coverage 41%
Duplication 22%
Rule violations 17%
Complexity 15%
Comments 5%

The strategy for coping with the technical debt is determined to a great extent through heat maps we generate as part of the engagement. Moreover, we construct a unified backlog that takes into accounts all work streams, not "just" technical debt reduction/elimination.

Jim Highsmith (www.cutter.com/meet-our-experts/jhbio.html) and I will be delivering a joint workshop on Technical Debt in the forthcoming Cutter Summit (www.cutter.com/summit/inreview.html). It will address in detail most of the good questions brought up in this thread.

Best,

Israel

This model uses the "cost accounting" fallacy by Jason Felice

... by assuming that you can divide a person's salary by the number of hours she works, then multiply it by the number of hours of a task to arrive at a "cost" for fixing the task. This doesn't work, because you don't pay salary employees hourly, and you hopefully don't cut their hours when there is less work, and you certainly can't throw a project to a contractor for two hours to get one block fixed. In other words, the organization pays the salary regardless of the technical debt, so the cost is elsewhere.

The only cost is opportunity cost. You need to know how the developers participate in the company's value stream and how the technical debt impedes the throughput of value. And if development has excess capacity (it either does, or it is the current bottleneck for value throughput), then the technical debt has no cost unless fixing is significant enough to lay someone off or repurpose them to a more valuable position.

Niave theory piece. by Chris Matts

First point. Developers compare technical debt to debt because generally they are not financially sophisticated. The executives on the board ( especially the CFO who you are trying to appeal to ) will understand that this is a "Sold Call Option". Simply put, The more popular/valuable the software, the more it will cost. When talking to execs, use the right financial metaphor. Debt to execs is a good thing.

My experience dealing with business executives is that they are pretty smart. If you explain the IT situation in terms they understand, they will be able to better "monitise" the effect than simply looking at developer costs. On a previous project we did a 6 man month effort to redesign the app to make it easier to test. The business execs understood the real impact of technical debt is not the trickle off extra developer resource, but rather...

1. The delay to implementing new features.
2. The risk of application failure.
3. The risk of introducing regression.
4. Other types of risk. (Operational, Reputation, Legal,...)

The cost of a bug to an organisation that takes down a customers operations if not the cost to fix the bug.

I would recommend engaging with your business execs in terms they can understand rather than present flaky numbers that would not convince anyone. The principles are more important than the numbers.