How to reduce Tech Debt: A Practical Experience Guide

So now we are going to talk about what technical debt really is and how we can reduce it. Everything you wanted to know is here – actual practical steps.

Let’s say, you want to outwork your competition and add features before competitors, the release date is pressing on you, and your client wants the new stuff right here right now. What do you do then?

Well, you might start working quickly and dirty – some examples:

• You “forget” to upgrade to the new release of the compiler.
• You don’t follow UI guidelines.
• You promised to add many features to client in a short period of time and now you are short in time.

As a result, you add something new and everything looks fine… until it is not. After the product release you start getting feedbacks from unsatisfied users: they found bugs and the client does not understand what is going on.

Congratulations, you have technical debt!

Technical debt is a metaphor that explains the situation when you have two choices of adding functionality: a long-term good solution that needs lots of time or a quick one but messy and unpredictable. When you choose an easy solution, you have tech debt which results in code problems, bugs, and difficulties with the delivery of future features.

Why does it happen?

In the study of the Software Engineering Institute,1318 qualified IT-developers defined the reasons for technical debt in Scrum. You can see the results in the diagram below or go to the original link.

As a company with the solid experience in reducing technical debt of software development, we created a list of the possible problem causes  based on the research above and our practice.

• Bad qualification of developers: they do not choose short-term solution over a long-term one – they don’t know alternatives;
• Competition and market pressure: team wants to outrun the competition, surprise users and bring new technologies to the market;
• Budget and time pressure, client wants everything right now;
• Ignoring the possible consequences of TD (happens especially with inexperienced developers). If you are not completely sure whether your developers have enough qualification and knowledge on how to calculate technical debt, don’t take a risk – go to experts.

Is the tech debt such a bad thing?

Not all the time. There are different types of technical debt – in some cases it might be actually a good thing.

Firstly, when you are a newcomer to the market, you have to impress users with your features and idea. Sometimes, you have to do it fast – before your competitor does. So spending time on a long-term solution is not the best idea. Remember, the fastest eats the slow – the faster you release something new – the bigger chances to stand out from your competition.

Secondly, sometimes technical debt is a part of your company’s growth: you release new features and products which help your clients and make your company well-known. If developers spend too much time on fixing insignificant bugs, it can be a straight road to stagnation.

How to manage technical debt using Agile?

We have already gone through main theoretical aspects of TD. So now it feels like time to discuss real practical actions: what you are going to do if you have technical debt?

Here we have some tips which have been proven to work by us and our colleagues.

You have to see your technical debt very clear

Keep a regularly updated Technical Debt List. In order to solve problems, you have to know exactly which problems you are going to solve. At QArea, we practice creating Debt Backlog: it is a comfortable technique which helps estimate the consequences, calculate the debt and track debt by its name.

Debt Backlog – My Natural Healer iPhone App

How to avoid technical debt – our Debt Backlog

SEI Research about Technical Debt showed that most executives, developers and project managers are unaware of their TD (42%), 26% had no opinion and only 10% were managing TD. Many companies are chasing new trends meanwhile forgetting the possible magnitude of its consequences (software can end up upgradeable or being a security risk).

Again, keep your enemies closer – know your technical debt and control it.

Make a schedule

When we talk about financial debt, it is obvious that you have to plan everything: what and when you are going to pay to get rid of the debt. You save money each week or each month and pay it. The same thing works with TD. It is important to have practical experience on how to reduce technical debt: for example, we organize the “clean-up” periods when all the developers work on reducing TD.

Do not let technical debt build up

At QArea, we practice “Boy Scout” rule which is: always leave the code cleaner than it was before. It is impossible to reduce technical debt all at once – do it one code at a time (and don’t forget to update your Technical Debt List in the process).

Recheck your definition of “Done” and “Ready”

You might need some changes. For us, it was helpful to add a “Review” column to our working boards. Also, we practice creating checklists – so developers double- and triple-check everything they work on.

Test your solution

Each developer knows that testing is important yet not everyone is doing it responsible enough. We made it a rule – to test each new solution because this is the most objective way to see each problem clear.

Use tools to manage TD

Research of SEI showed that only a few developers and managers are using tools to measure and track their technical debt. The most common of them are Duecode, JShint, Gitprime, Codegrip.  There is a list of tools and metrics of technical debt they listed – check it out yourself.

Tools used for managing technical debt according to SEI Research.

Talk to your client about TD and its cost

You can show some case studies that we talked about or show your risks calculation. When your client knows about possible TD, he or she is more likely to give you more time on the project.

Ensure stakeholders that architecture growth is akin to any application growth

For any new features that we add to an application, we should have an equal extension in architecture in the initial phases of a sprint. This practice has been well described in the SAFe framework as having an architectural runway that is parallel to the application runway. This can be planned based on the requirements of the application. This way, we’ll reduce technical debt by following proper engineering processes.

Plan and predict your technical debt in your developing process

Write it down, save the information and schedule the reducing date. If you are aware of possible consequences, it is much easier to reduce them (planning will save you plenty of time during your clean-up periods).

Let’s go through the main points one more time

• Before working on a project, calculate the possibility of having technical debt, analyze your architectural choices, add checklists and “Review” columns to your working boards.
• Technical debt is not necessarily a bad thing if you have calculated the risks and planned how you are going to reduce it in the process.
• Communicate with your team and client. If everyone knows about the technical debt in infrastructure, your work will be much more effective.
• Don’t be afraid to consult professionals. Everything that we described here looks easy at the first glance, but practically everything might be much more complicated. As a company which helps with reducing technical debts, we have seen cases where the project-managers wanted to reduce very complicated TD by their own – and in fact, they only made the situation worst.
• Don’t let the problems build up – leave the code cleaner than it was before, control bugs and update Technical Debt List.

If you feel like you can reduce your TD by your own, it is great – start doing it. But if there is a need for a consult or an expert advice or you feel like it is better to save your time – you are always welcome at QArea – our experts help reducing tech debt for more than 10 years!