In what I found to be a fascinating result the CAST Center for Quantitative Research reported on its Worldwide Application Software Quality Study – (CAST is a provider of software analysis and measurement solutions).
Bill Curtis, CAST’s chief scientist and senior vice president of the CAST Center for Quantitative Research, ran the study across 288 IT applications from 75 organizations (ranging from energy, financial, government and telecommunication sectors) which were statically analyzed for structural quality.
An business application with 374,000 lines of code was considered the average in this study, and the following results were derived on the basis that every application, when launched into production, carries with it an inherent liability for maintenance of errors as yet unknown which will need to be fixed.
They called this liability the “technical debt”. It’s a good term.
The technical debt is:
- about US$1m for the average 374,000 lines of code; under the following assumptions,
- US$75 as the average hourly wage of a developer; and,
- assuming each problem takes an hour to fix; and therefore
- the average maintenance cost per line of code was US$2.82.
Although the study did not go into the financial aspects, it implies means that if you cannot fund this debt through cashflow which is synchronized with the regular maintenance needs of the application then the application will degrade. That’s a truism, but now we have a quantifiable budget planning target which must be aimed for in order to maintain the quality of the code.
This means that, for example, Windows 7 had a technical debt of about $141m on launch (guessing 50 million lines of code) and Google’s Android – the mobile operating system – $34m (12 million lines of code).
They are relatively small numbers in the context of the investment, however it’s still a lot of money in absolute terms that could be better spent on enhancements than just fixing what has been released. As CAST says on their blog:
These findings stress the importance of fixing structural quality problems in order to avoid risks of outages, breaches, and other costly problems in the near future. If these high technical debts are prevented early on, IT executives can make much better use of their resources to develop new competitive functionality for their businesses.
Just to explore the concept of technical debt a little further, it could be said that if you can’t fund it then your application will become dangerously out of date. Or is it merely that you wont complete all the features that you’d like to have completed? Probably both. Technical debt would include “design debt” where you took shortcuts on design, and also operational shortcuts as in the following:
- the list of things which were deferred because they were too big for right now, or there isn’t a concept to deal with it, or because the chosen architecture is not compatible with a solution, etc;
- bad design decisions and shortcuts taken in order to ship, which some day will either have to be fixed, or face a bowl of spaghetti code that can’t be maintained or enhanced.
Technical debt effects start-ups in particular, and almost certainly at a much higher rate than the business applications studied. It’s not surprising to see early stage startups with high technical debt. The first version of their application was built either as a hack or very quickly built as a prototype that was never meant to scale, and with very limited funds. And that released code base is now supporting a growing community of users. Bradford Cross gives a comprehensive view of start-ups and technical debt and urges them to “think about the trade-offs you face and the financial impact of your decisions both now and over time.”
In this study, quality was focused on an application’s security, performance, robustness and changeability characteristics. Deeper analysis of the data revealed that newer, Web-facing technologies, such as Java EE and .NET, also scored lower in robustness, which are defined as “attributes that affect the stability of an application and likelihood of introducing defects when modifying it.”
CAST also theorized before the study that the size of any application would affect its quality. Consequently, this was found to not necessarily be true, Curtis said. However, modularity, or the “tightness of coupling between components,” has a direct impact on quality.
That’s an interesting finding with respect to the transition into loosely coupled Cloud ecosystems. It means that even in a very complex Cloud ecosystem if the coupling is relatively loose then the system as a whole should be more robust than an equivalent complex “self-contained” application.
Are you aware of other studies quantifying technical debt?
Do you think that the technical debt calculation is credible?
