HOW TO MANAGE TECHNICAL DEBT?

• Are your costs to maintain systems increasing?
• Do you find it challenging to hire people to work on your project?
• Does it take longer now to add new features than it did a year ago?

If the answers are positive, this could mean that your organization’s technical debt is growing and hampers your company’s agility.So it’s time to learn the ways how to manage technical debt effectively.

Watch a story about Jim and how he struggled with tech debt.

The Software Engineering Institute at Carnegie Mellon University provides the following technical debt meaning: “the tradeoff between the short-term benefit of rapid delivery and long-term value.”

Another perspective comes from Atlassian: “technical debt is the difference between what was promised and delivered.” In other words, it’s prioritizing speed and delivery over perfect code.

Let’s go back to Jim. He had to add new features to a software system, and at that moment, he had two options: either opt for a faster but compromised solution or take more time to finish the task but later rework the product in terms of resources and time.

Tech debt works the same way as financial debt. If you don’t repay the loan, it continues to compound until the loan principal ends up being much higher than the original amount.

The bottom line is that the longer you ignore technical debt, the more software entropy can occur.

Technical debt is not that bad. Almost every business has some degree of it. After all, the end-users do not notice the technical debt, so the companies often overlook it. For some time, this does not affect the functionality and quality of the product. But if you neglect managing technical debt over a long period of time, it can turn against your business. You have to keep the “we’ll fix it later” promise and do it properly.

Technical debt is acceptable for growing companies that need to release a new product version as soon as possible to test the waters, collect user feedback or analyze market needs.

99 % of projects have a certain amount of technical debt. The rest of them have not been released yet. 

But you still need to be careful about it and know how to manage technical debt; otherwise, it can lead to negative consequences. The more IT debt accumulates during the software development process, the more it can negatively affect the business and slow down the next release. So what causes IT debt?

• Business pressure to deliver the project to the customer earlier than it was estimated.

• Poor planning and prioritization of product backlogs when design and development start without proper requirements analysis.

• Poorly or hastily written code, when each developer writes code as they see it without adhering to specific coding standards.

• Legacy issues continue to generate a cost for the business.

• Lack of technical documentation. Documentation doesn’t need to be comprehensive: it could be wikis, collaborative documents, or code comments. Well-written and structured documentation allows developers to understand how a system works faster and speed up building new things.

• Lack of automated tests, including unit tests and end-to-end tests. Often, developers neglect to create automated tests until the end of the project. As a result, it’s harder to fix bugs and deploy changes that won’t break the build.

In a rapidly changing world, it is impossible to create a perfect product. The product teams should accept that there are no ideal products; there are under-analyzed ones. No matter how intelligent and talented team members are, a problem can always arise.

To properly register this debt, it is better to break it down into sources of origin. This will dictate how to deal with technical debt later on. Source examples are:

• versions of libraries and applications used;
• security problems;
• architecture errors;
• potential places for code improvement;
• warnings from compilers, interpreters and runtime platforms.

Technical debt isn’t something that can be effectively dealt with once and for all. Based on our experience, we suggest five ways of managing technical debt:

REFACTOR YOUR CODE

Refactoring is a systematic process of optimizing code and improving the internal structure without creating new functionality. In other words, refactoring is transforming a mess into a clean code without altering its external behavior.

Refactoring doesn’t mean adding new functionality, rewriting code, or fixing bugs. Refactoring transforms dirty code to reduce the overall technical debt and make your code more efficient and maintainable.

TECHNICAL DEBT TRACKING

Technical debt in software development architecture is difficult to measure – there’s no single metric to do it. It would help if you created metrics that make tracking technical debt easy. These metrics are specific to each project. We suggest tracking the impact of technical debt using business metrics, namely:

1. Cycle time: the length of time it takes to finish the task. The average cycle time shows how your developers perform from the first commit to the finish line.

2. Your current situation: use tools such as SonarQube and Coverity to measure the current state of your software technical debt and technical debt ratio (TDR). The TDR is a proportion between the price you pay to fix a software system (remediation cost) to the price you pay to assemble a new one (development cost). High TDR scores mean that software is in a deplorable state of quality.

4. Developer happiness: let’s be frank, if your developers are increasingly annoyed while working on a project, this could mean that there’s higher-tech debt in the system.
5. The number of bugs: after each iteration, we measure how many serious bugs are left unfixed. It allows us to plan bug-fixing activities for the next iteration. We also track the amount of opened bugs vs. the number of closed bugs. It allows us to be clear about whether our team is moving in the right direction regarding code quality.

USE PARETO PRINCIPLE

If you don’t know how much time you should dedicate to evaluating existing IT debt per iteration, we suggest using the Pareto Principle. Assign 20% of your engineering activities to technical debt and 80% to daily tasks. In this way, your team will devote the majority of the time to the main functions, while also managing technical debt effectively.

REMEMBER ABOUT UNIT TESTS

Writing and conducting unit tests more frequently is a way to eliminate regression bugs and recover from technical debt. With unit tests, your development team will improve the code quality, identify bugs more efficiently, and automate the testing process.

TREAT TECHNICAL DEBT AS PART OF YOUR BUSINESS STRATEGY

Research by Gartner says that companies that have a strategy for how to handle technical debt will ship 50% faster.

Embed technical debt into your project roadmap. It would help if you had a strategy for how much time you’ll spend paying off tech debt: fixing bugs, reviewing code, and reducing the overall debt to build a more resilient product.

Agree with your development team on how much time you want to devote to managing technical debt. For instance, you might prefer your team to focus on the health of the codebase each sprint or quarterly. Alternatively, you might decide on delivering new features to be the first on the market, then perhaps growing technical debt may be the right decision for you. Establish a clear definition of done in your team, including quality metrics.

Is tech debt that bad? Yes and no. We are used to considering software technical debt as something scary and unacceptable. In a perfect world, it is. But the reality is that tech debt is part of every digital project. The only difference is some know how to manage technical debt effectively, while others don’t. Tech debt is like credit cards: sometimes, they are helpful and come in handy. They allow you to get something faster than you could without them.

“If you’re not embarrassed by the first version of your product, you’ve launched too late.” Reid Hoffman

According to Martin Fowler’s technical debt quadrant, it is necessary not to define whether technical debt exists but rather to learn how to identify it.

• Deliberate & Reckless: you know that you are making a design decision that will inevitably create technical debt. It’s a rarely practiced strategy. The development team feels the business pressure to deliver products faster knowingly violated best practices.

• Deliberate & Prudent: “acting with or showing care and thought for the future.” This technical debt quadrant is about being aware of taking a debt.

• Inadvertent & Reckless: “things you really should have known but didn’t.” A team with industry knowledge should be able to avoid this type of tech debt.

• Inadvertent & Prudent: when you are doing something new, you inevitably reach the point when you say: “If only I had known this before, I would have done it differently.” No amount of analysis can predict what you’ll learn over a software product’s lifetime.

1. Technical debt can be your ally if you need to buy time and ship a product faster to the market.
2. The best option is to avoid debt, but you are unlikely to succeed.
3. Don’t consider rewriting the entire system as the only viable solution.
4. Tech debt decreases productivity, so try to get rid of it as quickly as possible.
5. Don’t confuse tech debt with a typical mess.
6. Don’t chase the perfect product.

Technical debt is holding you back? Let’s fix it.