The cost of technical debt: 3.61$ / line of code

We've all heard of all kinds of metaphors regarding technical debt, but until recently, I never knew of any study that could put a price tag on it.

 I guess I'm not the only one unaware of the existence of such a study because I've heard of developers almost crying (before flying away from there) because businesses are not keen on writing tests or refactor code, mainly because the cost of this walk on thin ice is not quantifiable in money.This is an issue of the past, because this study from CAST exposes millions in very well hidden IT costs.Some conclusions from the above article:

• technical debt costs companies $3.61 per line of code
• outsourced and in-house developed applications didn’t show any difference in structure quality
• neither did onshore and offshore applications
• established development methods such as agile and waterfall scored significantly better in structural quality than custom methods
• waterfall scored the highest in transferability and changeability (a surprise from my point of view)
• government systems tend to be the lowest in maintainability (I thought this was expected only in Romania)
• the more frequently the code is released the higher the technical debt (another surprise for me)

In recent years I've seen an increased interest from companies in paying for QA - rapidly moving from manual testing to more automated testing.

I believe that until recently (the last 5-10 years), since most applications were desktop based, an app was either rewritten in its entirety in order to make it look&feel modern, or replaced by a competing, good looking one. 

Since the web got traction, a company gets a much lower cost in just changing the UI and keeping adding features in the backend than rewriting the whole app. 

One issue with this, is that there are pretty small chances that code that is 10+ years old is up to date with the latest technologies (like for example, using Memcached for keeping context). 

Every developer that has to interact with that code, has to work like 10+ years ago - what developer wants that? (maybe COBOL developers, who might consider code of that age as being bleeding edge )

On the other hand, 10+ year old code brought money and it still does - who would risk the business in order to rewrite that? (I wouldn't allow such a risk on my software)

The solution is to have unit tests for all the code you intend refactor so that you can be almost sure that the changes you make don't have negative side effects.

Is this a personal impression or we really getting an ascending trend regarding automated testing?

Update:

This post is mentioned in the Perl Weekly Newsletter - there Gabor asks some good open questions regarding potential conclusions like what should we do :

• Throwing away the old and partially broken code?
• Adding automatic tests to the existing application? 
• Nothing?

I'd conclude, that first of all, we should have a general impression regarding the price we have to carry on with us because of the technical debt. I have written a follow-up article regarding possible ways to get a cost for technical debt in Perl . 

I think it is possible to get an application to a stage in which is much more profitable to rewrite the whole application or parts of it instead of continually paying interest for the debt. 

With a technical debt calculator, we could take much more pertinent decisions to questions like:

• Is it profitable going on like this, or we should do a rewrite?
• Why we pay so much for maintenance instead of bringing new features to market?
• Why in the early life of the application 2 developers were bringing 3 features per week, and now, 5 developers get out 2 features in 3 weeks?

And the questions could go on and on.

Share this article: