The foolish man builds his house on loose sand but the rains and the winds will crash it. (Matthew 7:24-27) Things have not changed that much in the last two thousand years. Technical debt remains a major challenge for software development teams.
Technical debt ties up resources
[bibshow]You cannot be agile if you are bogged down by technical debt. Too much of your budget will go to application management and not enough will be available for development and innovation. Older systems are harder to maintain. [bibcite key=”citeulike:9962168″] Take the example of Telefonica in Spain for instance. They were able to free up 14 billion € in debt and 18% of their total IT spend. Part of the reason for that was that they removed thousands of legacy systems ridden with technical debt. Imagine what you could do with that kind of money. For Telefonica technical debt reduction meant a return to profitable growth. [bibcite key=”citeulike:13557524″]
Technical debt makes innovation hard
Technical debt makes innovation slower for you. Technical debt reduction is very important for those who want to be agile and nimble. It is not just because your budget is tied up in renovation work. It is also because it is harder to build on a less than solid foundation. Developer productivity is adversely affected by technical debt. Griffith et al gives a simplified formula for developer productivity as an effect of technical debt. Here is a slightly adapted version: [bibcite key=”citeulike:13557543″]
That formula is probably not aggressive enough. As technical debt and system size grows productivity probably goes below zero. That is, any attempt you make to improve the situation actually makes it worse. This is probably worse for junior developers. They will have even bigger problems in dealing with low quality.
If technical debt is so bad – it ties up your money and prevents you from innovating – what should be done about it? There are three things you can do about it: keeping track of it, avoiding it and reducing it. Let’s look at each of these topics.
Technical debt monitoring
You know what they say: “The first step towards solving a problem is recognizing that there is one.” I guess what you should monitor are the process outcomes. You spend a significant part of your IT budget on infrastructure and maintenance and can only dedicate a small part to innovation. You have lots of innovations that you want to push out but it takes too long and you can only push so much through the funnel. If these metrics are unavailable or not fine grained enough, you will need to look at more technical metrics.
My current employer, Capgemini, offers a range of services where Tech Debt matters. These services include WARP, LINKS, AL2 and AM NG. These services are not all about technical debt reduction but it is one of the parameters that we evaluate when we look at the clients ecosystem of applications. How is it done?
To determine tech debt a number of lenses are applied including incident stats and source code analysis. Static source code analysis can be done with tools like CAST. CAST produces an amount, a total technical debt of the system under study. CAST calculates this as the sum of the product of the number of defects at each severity level and the typical cost to fix a defect of that severity. [bibcite key=”citeulike:13558592″] While that number might not be totally accurate – e.g. not all defects require fixes and not all technical debt can be autodetected [bibcite key=”citeulike:13244091″] – it will still give you the ability to compare and trend technical debt across applications.
Application maintenance is a much more complex problems than what can be predicted by technical debt alone. A study by Magne Jorgensen shows that predicting maintenance cost is very hard. At the same time, there is enough flexibility that maintenance teams are usually able to meet their budgets. [bibcite key=”citeulike:2483658″]
Technical debt avoidance
If you are already monitoring your technical debt, you will want to avoid to increasing it. There is no point in adding technical debt now that you know what it does to your ability to innovate, or is there? So what should you do to avoid adding to your technical debt? Is it perhaps enough to create a schedule for “state rejuvenation” where you simply restart your software now and then? [bibcite key=”citeulike:13565265″]
Technical debt avoidance is both hard and not hard. If you do agile the right way, you will avoid adding new technical debt to your software more or less automatically. If you are doing agile right, you are implementing such key agile practices as continuous integration, automated unit testing, refactoring, complete feature testing and test driven development. [bibcite key=”citeulike:12799124″] But there are many teams, which in practice, do not do agile right.
If you are already doing the right things, make sure you do them the right way. If you haven’t really started doing the right things, do that now. Do you really want to add more technical debt at this point?
Perhaps you do? Perhaps you are so pressed about time-to-market now, for this feature, that you are willing to forego speedy delivery later? [bibcite key=”citeulike:13565270″] Are you sure that the future will happen as planned?
Technical debt reduction
You know about your technical debt. You have largely been able to avoid adding new debt. You are ready to start chipping away at your mountain of technical debt. What is your best way to technical debt reduction? Let’s look at a fairly common situation as shown in the figure below.
In the figure, the development team performs four sprints followed by a release. It might not be everyone’s ideal way to do agile software development. It certainly isn’t devops. But it is how many of us work.
I am not going to go into how you should precisely go about reducing your technical debt. Let’s look at three overall strategies you can apply as I have tried to illustrate in the following figure. We are still in the same situation as above with the difference that we know we have technical debt and that we need to do something about it.
At any point in time, you can choose to work on reducing technical debt or on adding new functionality. As you do that, you produce some form of work results which affect the size of the technical debt (red) and the size of the functionality (or value or code base or …) (green) that your product delivers.
Your technical debt management will have three main components as outlined above: technical debt monitoring, technical debt avoidance and technical debt reduction.
Technical debt monitoring is about making sure that your technical debt does not grow to overwhelm you. Ideally, it should decrease as the system grows.See here for a similar concept in test suite monitoring.
Technical debt avoidance is about doing the work (execution) in a way that does not increase technical debt. Examples of things you could in addition to what I listed above: enforcing coding standards, pair programming and refactoring.
Technical debt reduction is about selecting when, how much and what work to do that reduces technical debt. You should budget for a fixed percentage of your efforts for technical debt reduction.
- Test coverage versus percentage of code that is test: Owned by the author
- four sprints and a release: Owned by the author
- four sprints and a release – three strategies: Owned by the author
- a model of technical debt management: Owned by the author
- house on loose sand: Lee Shaver via Flickr | CC BY NC SA 2.0