Using Credit Limits to Constrain “Development on Margin”
Buying (stocks) on margin is broadly recognized as a risky investment strategy. Funding long-term investments with short-term debt exposes the investor to margin calls as he/she might not be able to secure more financing when needed. The resultant margin call is never pleasant.
The accrual of technical debt in the course of aggressively developing functions and features is quite a similar phenomenon. The CTO is betting the functionality he/she is developing will pay off before the need to “pay back” the technical debt becomes imperative. The temptation to do so is particularly strong due to the lack of credit limits on technical debt. For all practical purposes the CTO is “developing on margin.”
In his comprehensive studies of the economics of software, Capers Jones has actually put a 3-5 year ceiling on the economical viability of developing on margin:
Indeed, the economic value of lagging applications is questionable after about three to five years. The degradation of initial structure and the increasing difficulty of making updates without “bad fixes” tends towards negative returns on investment (ROI) within a few years.
As the CEO leading a company, or the venture capitalist funding it, you can restrain development on margin by establishing credit limits. Use a combination of static code analysis with dynamic program analysis to calculate the amount of accrued technical debt in $$ terms. (An illustration of such calculation as well as a breakdown of the technical debt is given in the Sonar chart above). Set a limit (say $0.25 per line of code) on the amount of permitted technical debt. Once the limit is reached, developers are not allowed to continue developing new functionality – they have to first reduce (and hopefully eliminate) their technical debt.
A very simple “Lacmus test” is available to the CEO/VC until the code is instrumented and the analytics illustrated above generated. Ask your CTO about unit test coverage. If the coverage is low (say <30%), chances are the technical debt is high. Whether the CTO realizes it or not, low unit test coverage is a good indicator of technical debt of all kinds. Moreover, the investment required to develop a full-fledged suite of unit tests is often the largest component of the technical debt to be paid back.
The Agile Executive 
[…] assess the investment decision, apply the code analysis techniques described in Using Credit Limits to Constrain Development on Margin to quantify the technical debt. Assuming a debt of $2 per line of code has been identified, the […]
Should You Invest in This Software?! « The Agile Executive
March 4, 2010 at 5:44 am
[…] Using technical debt quantification techniques you find the technical debt amounts to $1M. […]
How to Combine Development Productivity Data with Software Quality Metrics « The Agile Executive
March 8, 2010 at 5:33 am
I really like the analogy to buying stocks on margin. Many business managers have a hard time understanding the concept of technical debt. Comparing to a financial instrument that is familiar to many is very helpful.
Paul Brownell
March 10, 2010 at 8:58 am
[…] the techniques outlined in Using Credit Limits to Constrain Development on Margin to calculate technical debt before and after. In addition to qualifying your Agile success, […]
Measuring Agile Success Rate the Right Way « The Agile Executive
March 12, 2010 at 5:37 am
[…] you accrue the debt. Running technical debt analytics on the source code every two weeks is a good practice to […]
How to Initiate a DevOps Project « The Agile Executive
March 17, 2010 at 5:32 am
[…] Using Credit Limits to Constrain “Development on Margin” By Israel Gat, 1 March 2010 “Buying (stocks) on margin is broadly recognized as a risky investment strategy. Funding long-term investments with short-term debt exposes the investor to margin calls as he/she might not be able to secure more financing when needed. The resultant margin call is never pleasant.” […]
Sonar » Sonar in the news
April 6, 2010 at 6:23 am
[…] is a little tricky (though not impossible – see Using Credit limits to Constrain Development on Margin) to define the precise point where technical debt becomes “unmanaged.” One needs to […]
Can Technical Debt Constitute a Breach of Implied Warranties? « The Agile Executive
April 7, 2010 at 5:03 am
[…] post Using Credit Limits to Constrain “Development on Margin” proposed a way of coping with the vicious cycle of technical debt – placing a limit on the […]
How to Break the Vicious Cycle of Technical Debt « The Agile Executive
September 20, 2010 at 6:43 am
[…] Why $10 and not $1 or $100 per line of code? It is a matter of balancing investment versus debt. An average programmer (in the US) with a $100,000 salary would probably be able to produce about 10K lines of Java code per year. The cost of a line of code under these simplistic assumptions is $10. Something is terribly wrong if the technical debt exceeds the cost per line. They call it living on margin. […]
How Technical Debt Ties to Cloud, Mobile and Social « The Agile Executive
October 11, 2010 at 4:46 am