Technical Debt on Your Balance Sheet
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.
The Agile Executive 
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.
Balaji_Getfriday
September 30, 2009 at 2:00 pm
Thanks for the kind words, Balaji!
Please see Can You Afford the Software You are Developing
(https://theagileexecutive.com/2009/02/01/can-you-afford-the-software-you-are-developing/) in this blog.
Israel
israel Gat
September 30, 2009 at 4:45 pm
[…] a comment » As I learned the hard way, the post Technical Debt on Your Balance Sheet missed an important risk associated with technical […]
Sign of the Times « The Agile Executive
October 1, 2009 at 5:18 pm
[…] little article – Technical Debt on your Balance Sheet https://theagileexecutive.com/2009/09/29/technical-debt-on-your-balance-sheet/ Share and […]
Excellent little article – Technical Debt on your Balance Sheet | Agile Advice - Working With Agile Methods (Scrum, OpenAgile, Lean)
October 2, 2009 at 3:53 pm
Click http://tinyurl.com/mb84yk for the formulas used to calaculate the monetary value of technical debt.
Israel
Israel Gat
October 4, 2009 at 10:21 am
[…] 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 […]
Elbow Room for Handling Technical Debt « The Agile Executive
October 7, 2009 at 6:56 pm
[…] 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 […]
Clear Costs and Technical Debt « Unstable Terrain
October 11, 2009 at 5:09 pm
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
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.
Trent
October 12, 2009 at 10:21 pm
[…] 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 […]
Your Investment in Enterprise Software – Guidelines to CIOs and CFOs « The Agile Executive
November 19, 2009 at 9:58 pm
[…] 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 […]
It Won’t Work Here « The Agile Executive
December 7, 2009 at 5:46 am
[…] 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. […]
The Headlong Pursuit of Growth, and Its Aftermath « The Agile Executive
December 15, 2009 at 5:18 am
[…] 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: […]
Cloud Computing Forecasts: “Cloudy” Future for Enterprise IT « The Agile Executive
February 1, 2010 at 5:32 am
[…] accrual of technical debt in the course of aggressively developing functions and features is quite a similar phenomenon. The […]
Using Credit Limits to Constrain “Development on Margin” « The Agile Executive
March 1, 2010 at 1:43 pm
[…] 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 […]
Forrester on Managing Technical Debt « The Agile Executive
September 1, 2010 at 8:58 am
[…] 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 […]
Sorting out “cloud security”
April 19, 2011 at 4:44 pm
[…] 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.” […]
Transactions for Managing Technical Debt | The Agile Pirate
August 7, 2011 at 5:25 am