The Agile Executive

Making Agile Work

Technical Debt on Your Balance Sheet

with 17 comments

Colleague Jonathon Golden introduced me to a new plug in to Sonar. The plug in calculates the cost to fix the technical debt accrued in a product. For example, you might find an accrued technical debt amounting to $1M in a 500KLOC application. Obviously, you will need to spend $2 per each line of code to “pay back” your debt.

The expression of technical debt in monetary terms is intriguing. Unlike financial debt, there is no credit limit on technical debt. Hence, unless a team is proficient at refactoring on an ongoing basis, technical debt tends to grow over time as the underlying software decays. 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. Under such circumstances, most/all of the development team gets sucked into maintaining the software instead of developing new features and functions.

Monetizing technical debt can have two far reaching implications, as follows:

  • A credit limit on technical debt can be established.  For example, when the technical debt reaches a certain level (say 25 cents per line of code), new functionality is put on hold. The team applies itself to aggressive refactoring to reduce the debt to an acceptable level.
  • For companies who capitalize software, technical debt could become a line item on the balance sheet. It will simply be listed as a liability.

From a customer perspective, the monetized technical debt on the balance sheet of a software vendor is a proxy for the technical risk involved in licensing software from this vendor. Such monetization could be easily extended to report technical debt per product family. With such reporting in place, the technical risk associated with licensing a specific product can be assessed.

Software vendors might frown at the requirement to monetize technical debt. I would contend that such a reporting requirement is absolutely consistent with the spirit of the Agile Manifesto:

Customer collaboration over contract negotiations

In other words, if you are reluctant to list your monetized technical debt you can’t really claim you practice Agile.

Written by israelgat

September 29, 2009 at 8:18 pm

17 Responses

Subscribe to comments with RSS.

  1. Wow, I hadn’t thought about it that way before. Good write up, very clearly written. Have you written previously about this Technical debt Topic? I’d love to read more.


    September 30, 2009 at 2:00 pm

  2. Thanks for the kind words, Balaji!

    Please see Can You Afford the Software You are Developing
    ( in this blog.


    israel Gat

    September 30, 2009 at 4:45 pm

  3. […] a comment » As I learned the hard way, the post Technical Debt on Your Balance Sheet missed an important risk associated with technical […]

  4. Click for the formulas used to calaculate the monetary value of technical debt.


    Israel Gat

    October 4, 2009 at 10:21 am

  5. […] which the software is applied, the situation is usually characterized by an overwhelming amount of technical debt accompanied by an unaccptably high error feedback ratio. Between those “twins”, both […]

  6. […] a comment » Israel Gat wrote about putting technical debt on the balance sheet. It sounds appealing, but when you try to bring the concept of technical debt into the financial […]

  7. In response to Trent’s post in Unstable Terrain: the question IMHO is not what an accountant does today, but whether the concept of technical debt on the balance sheet is useful. I might be biased, but I would contend it is a potentially powerful concept in quite a few ways. For example, for contracts, revenue recognitions and M&A purposes.

    One important point that should be emphasized in the balance sheet context is that technical debt is much broader than “not performing enough maintenance.” Technical debt, even in well managed projects, is due to software evolution and software decay. As such, it is intrinsic. One would hope it is only a matter of time till accounting standards evolve to reflect this reality.


    Israel Gat

    October 11, 2009 at 8:15 pm

    • I agree that the concept is fine, even laudable. it allows for some really useful concepts like removing externalities due to ‘sweating your software assets’.

      I guess my main point was that there remains significant barriers (regulatory etc) to overcome before it’s feasible.


      October 12, 2009 at 10:21 pm

  8. […] amount of technical debt. Ask the vendor to quantify the technical debt in monetary terms. See Technical Debt on Your Balance Sheet for an example how to conduct such […]

  9. […] your software. Tools are readily available to quantify your company’s technical debt. Monetize the technical debt and include it as a liability line item in a pro forma balance sheet. Doing so is likely to shift […]

  10. […] If your company relentlessly pursues growth, the quality/technical debt liability it is likely to incur coud easily outweigh the benefits of growth. Consider the upside potential of growth vis-a-vis the downside of the resultant technical debt. When appropriate, monetize technical debt using the technique described in Technical Debt on Your Balance Sheet. […]

  11. […] audit of the technical debt should be conducted before “clouding” an application. See Technical Debt on Your Balance Sheet for a recommendation on quantifying the results of the quality audit. Possibly related posts: […]

  12. […] accrual of technical debt in the course of aggressively developing functions and features is quite a similar phenomenon. The […]

  13. […] quality in the portfolios of projects/products a company possesses. As mentioned in an earlier post, companies who capitalize software will sooner or later need to report technical debt as line item […]

  14. […] suspect this is the one of the real problems with “cloud security”: calling in the technical debt you’ve accumulated under the security column over the years. Folks like CohesiveFT would suggest that they have […]

  15. […] Here’s the quote from Israel back in December ’09. “If your company relentlessly pursues growth, the quality/technical debt liability it is likely to incur could easily outweigh the benefits of growth. Consider the upside potential of growth vis-a-vis the downside of the resultant technical debt. When appropriate, monetize technical debt using the technique described in Technical Debt on Your Balance Sheet.” […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: