Budget for Technical Debt Reduction

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.

Source: Owned by the authorIf 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.

Source: Owned by the author

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 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.

Source: Owned by the author

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. You have already planned for your technical debt reduction.
• Fixing bugs is easier if you do it earlier, rather than sooner.
• Because estimating bug fixing is hard, after you fix all your bugs, your schedule will have less risk in it.

Hardening sprints

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 and from production and try to renovate the product back to a releasable state so that the release can take place as planned. I don’t think anyone really 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, perhaps 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 that it is not all that relevant.

Other strategies

There are 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 it is not really what you want to do, is it?

So, what should you do? There was a recent scholarly article that 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.

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 on reducing technical debt if the debt is above a certain threshold and otherwise to dedicate a fixed percentage of your available effort to debt reduction.

Does debt reduction include outright bugfixing? No, bug fixing you still have to do as soon as possible. What I am talking about here is reducing risk, not handling issues.

Summary

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.

Source: Owned by the author

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 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.

References

[/bibshow]