“The foolish man builds his house on loose sand but the rains and the winds will crash it.” (Matthew 7:24-27) Things haven’t changed that much in the last two thousand years, as technical debt remains a major challenge for software development teams.
Technical debt ties up resources
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 simply harder to maintain.  Take the example of Telefonica in Spain for instance. They were able to free up €14 bn in debt and 18% of their total IT spend by removing 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. 
Technical debt makes innovation hard
Technical debt makes innovation slower for you, and technical debt reduction is very important for those who want to be agile and nimble. It’s not just because your budget is tied up in renovation work – it’s also because it’s harder to build on a less-than-solid foundation. Developer productivity is adversely affected by technical debt as well. Griffith et al gives a simplified formula for developer productivity as an effect of technical debt. Here is a slightly adapted version: 
That formula is probably not aggressive enough. As technical debt and system size grows, productivity probably goes below zero. In other words, any attempt you make to improve the situation actually makes it worse. This is probably worse for junior developers, who will have even bigger problems in dealing with low quality.
If technical debt is so bad, tying up your money and preventing you from innovating – what should be done about it? There are three things you can do about it – keep track of it, avoid it and reduce it. Let’s take a 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.” Accordingly, what you should monitor are 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 plenty 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 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 client’s 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 for the 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. 
While that number might not be totally accurate (e.g. not all defects require fixes and not all technical debt can be autodetected ) it will still give you the ability to compare and trend technical debt across applications Application maintenance is a much more complex problem than what can be predicted by technical debt alone. A study by Magne Jorgensen shows that predicting maintenance cost is very hard, but at the same time there is enough flexibility that maintenance teams are usually able to meet their budgets. 
Technical debt avoidance
If you are already monitoring your technical debt, you will naturally want to avoid to increasing it. 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? 
Technical debt avoidance is both difficult and easy. 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.  But there are many teams which do not do Agile right in practice.
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, now is a good time to start – 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?  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, and 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.
Some teams work like this. A number of sprints followed by a release.
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, which 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.
Three strategies for technical debt reduction based on a scenario of four sprints followed by a release. The first strategy is to fix all bugs first before any “useful” work is done. The second strategy is to handle tech debt at the end, just before the release. The final strategy is to work off tech debt a bit in each sprint.
Fix all bugs first
At the top, we have a strategy that we could call “fix all bugs first.” Joel Spolsky asks “Do you fix bugs before writing new code?” The advantages of this strategy are manifold:
§ When you add new functionality, you will do it on a clean code base – no building on loose sand
§ When you cheat and intentionally add tech debt to meet a deadline, you know that it won’t stay, as you have already planned for your technical debt reduction
§ Fixing bugs is easier if you do it earlier rather than later
§ Because estimating bug fixing is hard, after you fix all your bugs your schedule will have less risk in it
The second strategy for when to do tech debt reduction can be called “hardening sprints.” With hardening sprints, the team will gather up all bugs that were discovered during the previous sprints (as well as from production) and try to renovate the product back to a releasable state. I don’t believe anyone really thinks hardening sprints are good ideas. Sometimes, you must have hardening sprints. Most people do have them in some form or another. If you find that you must have hardening sprints, it’s just perhaps possible that you are doing something wrong.
Do a little every sprint
The final overall strategy is to do a little every sprint. Just like the bank asks you to pay off your mortgage every month, so does your code ask you to amortize your technical debt a little every sprint. This approach will take a little debt away each sprint while allowing you to continue to deliver functionality. A team that stops delivering functionality for any length of time will soon find itself irrelevant.
There are of course other strategies that you could apply. Ignoring the technical debt is one, having the maintenance team deal with it is another. Most of us do some of this “ostrich” stuff from time to time but these aren’t really solutions that are built to last, are they?
So what should you do? A recent scholarly article prompted me to start writing this post.
Our study shows that combining a prioritized list of technical debt items in parallel to the development backlog, while continuously monitoring for both known and unknown technical debt items and focusing either a percent of sprint effort or all of every nth sprints effort on technical debt remediation sprints is the superior combination of practical technical debt management technique.
Griffith et al 
So what does that mean to you? You should start fixing your technical debt now and keep fixing it while still remembering to deliver useful functionality. Griffith et als study was based on the above release train model, where a release pulls a number of sprints behind it. If you are in a more agile model with shorter time between releases, dedicating a full sprint every few releases will not be good enough. If you are in that situation (or if you are doing devops) your best strategy will probably be to dedicate all efforts to reducing technical debt (if the debt is above a certain threshold) and dedicating a fixed percentage of your available effort to debt reduction.
Does debt reduction include outright bug fixing? No, bug fixing still needs to be done as soon as possible. What I’m talking about here is reducing risk, not handling issues.
Thank you for reading all the way to the end of this post. Here’s a little bonus to thank you for your tenacity.- a figure that summarizes the gist of what I have written.
A simple model of technical debt and how to manage it through monitoring, avoidance and reduction.
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 work results that affect the size of the technical debt (red) and the size of the functionality (or value or code base or whatever) (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 do in addition to what I listed above include enforcing coding standards, pair programming and refactoring.
Technical debt reduction is about selecting when, how much and what work to do in order to reduce technical debt. You should budget a fixed percentage of your efforts for technical debt reduction.
 B. P. Lientz and B. E. Swanson, “Problems in application software maintenance,” Commun. acm, vol. 24, iss. 11, pp. 763-769, 1981.
 C. Francois, J. Buvat, and R. Nambiar, “The digital transformation symphony: when IT and business play in sync,” Capgemini Consulting 2014.
 I. Griffith, C. Izurieta, H. Taffahi, and D. Claudio, “A simulation study of practical methods for technical debt management in agile software development,” in Proceedings of the 2014 winter simulation conference, Piscataway, NJ, USA, 2014, pp. 1014-1025.
 B. Curtis, J. Sappidi, and A. Szynkarski, “Estimating the principal of an application’s technical debt,”Ieee software, iss. 6, pp. 34-42, 2012.
 P. Kruchten, R. L. Nord, and I. Ozkaya, “Technical debt: from metaphor to theory and practice,” Ieee software, vol. 29, iss. 6, pp. 18-21, 2012.
 M. Jorgensen, “Experience with the accuracy of software maintenance task effort prediction models,” Software engineering, ieee transactions on, vol. 21, iss. 8, pp. 674-681, 1995.
 K. S. Trivedi, K. Vaidyanathan, and K. Goševa-Popstojanova, “Modeling and analysis of software aging and rejuvenation,” in Simulation symposium, 2000. (ss 2000) proceedings. 33rd annual, 2000, pp. 270-279.
 L. Williams, “What agile teams think of agile principles,” Commun. acm, vol. 55, iss. 4, pp. 71-76, 2012.
 E. Lim, N. Taksande, and C. Seaman, “A balancing act: what software practitioners have to say about technical debt,” Software, ieee, vol. 29, iss. 6, pp. 22-27, 2012.
This post was originally posted on my personal blog www.gregerwikstrand.com. You'll find it here.