Technical Debt and How It Impacts Your ROI

As with any type of debt, technical debt happens when you borrow from the future for today. You select a solution that will be fast and easy to develop — a solution that will get you past your major hurdles. But you know that the solution won’t be as elegant or well-optimized as it could be, and you know that it will make development more complicated later on.

Every project has some level of technical debt, and technical debt isn’t always bad. It’s not feasible to pursue the most sophisticated solution every single time: a project would never get completed. But performing a cost-benefit analysis regarding technical debt is still important, especially when considering the total ROI of a project. Long-term, reducing technical debt as much as possible will lead to better results.

Technical Debt: an Exponential Problem

Technical debt tends to cascade, becoming an ever-increasing issue that developers need to handle. As solutions become more complex, the technical debt of earlier decisions are magnified. As projects continue, the debt will layer upon itself, and the system itself will become resource-intensive and unstable. Every modification, optimization, and improvement will become more difficult.

When someone programs a solution quickly, they might write 1,000 lines of code. But with some additional thought, those lines of code become 100. An elegant solution is easier to maintain, but it’s also harder to write.

Likewise, hard-coding a solution to a program may be fast and easy, but it makes it harder to change the program later on. Most companies can’t completely eliminate their technical debt; there just aren’t the resources available. But companies can work to manage and reduce that debt.

There are really three major types of technical debt:

• Deliberate debt. This happens when engineers decide that it’s simply not worth it to engineer a perfect solution. A system may work a little more slowly, but it will work. The code may be a little convoluted and complex, but it gets the job done.
• Accidental debt. This happens when outdated solutions are used, or no one looks into how well-optimized a solution is. Engineers might port in some old “spaghetti code” in hopes that it will run. And it does, but not well.
• Organic debt. This happens when a system organically changes over time, adding inefficiencies each time. Programmers add onto a feature rather than updating the feature from the ground up, and it becomes cumbersome.

With deliberate debt, the question is simply whether the cost-benefit analysis is correct. Sometimes a project may change in scope later on and the technical debt involved may become more relevant than it was before.

With accidental debt and organic debt, it’s more important to have a system of controls in place. Accidental debt only happens if no one is looking at streamlining and optimization, and organic debt happens because revision processes aren’t being properly tested and controlled. Often, organic debt will happen because the iterative process isn’t properly managed.

The Impact of Technical Debt on ROI

Take a single, small application. When it’s run once or twice, issues of technical debt are likely not even noticeable. But when that application is run hundreds of thousands of times on a single server, the technical debt will be greatly magnified. Issues of technical debt often occur when the product is expected to be able to operate to scale.

For an end user, the issues related to technical debt are quite clear. An application with a lot of technical debt is going to be sluggish, slow to perform. It’s going to cost a company efficiency and productivity, and it’s going to force them to struggle against the application in order to complete their work.

For the product owner, every time a request is made, the labor will be extensive. Because the code hasn’t been optimized and isn’t written elegantly, the programmers will take a long time to implement any changes.

And for the companies developing applications, technical debt makes the end application a harder sell, because of the significant amount of resources the application needs to use. Technical debt makes it harder to continue modifying and improving upon the application, because the application will increasingly become unstable and unwieldy.

During the process of development, technical debt has a way of catching up. While it may have saved hours at the very beginning of development, it will take even longer to fix at the end of development. Entire applications may need to be overhauled. Thus, large amounts of technical debt are generally never good for a company’s ROI.

Thus, technical debt is going to lengthen the product’s runway at the end. While it may make the product’s development faster at the beginning, the product will start to get bogged down towards the end of it. Developers are going to have to work harder to address the issues that were introduced at the beginning, and may not even be aware of what issues they will find.

Planning Ahead for Technical Debt

The consequences associated with technical debt can be side-stepped through careful planning. Through better planning, a company can decide upfront where its technical debt will be. A company can decide which areas of an application will involve more work, and which parts of the application can hold debt for some time. Planning ahead will reduce the chances that the organization will need to assess its work and commit to a rework early on.

This is a lot like building the proper foundation to a construction project. Companies need to work to understand the ultimate structure of the product that they’re working on, as well as the ideal scale of the product that they’re working on. A company needs to have a clear idea of its product goals before it begins developing that product.

Since there will always be some level of technical debt, this gives a company a superior amount of control. The company is able to decide from the very start that it will have technical debt and how much technical debt it will have. From there, the company can calculate how much ROI is being lot to certain elements of technical debt, and whether the ROI is ultimately positive.

Further, there can be strategies and contingencies in the event that the product eventually exceeds its planned scale. By tracking technical debt, a company will be able to more easily address that debt later in the project.

Eliminating Technical Debt: The Best Practices

Tech debt is usually caused by poor controls and bad software development practices. Improving upon processes can help. Technical debt is most likely to occur when a project is very loosely controlled, with a number of different pieces of code patched together to resemble something like a complete system. The more there is a diffusion of responsibility, the less likely it is that anyone involved will be taking a look at the technical debt.

To eliminate technical debt, it becomes important to improve software development practices. Strictly control the way that changes are requested and made. Keep multiple versions available. Test the product at intervals and make sure that those tests don’t have any signs of debt. Ensure that all the engineers are aware that the application should avoid technical debt, and that it’s better to make changes now rather than later.

Technical debt often happens when companies are under a crunch. If a company is pushing a very tight, rigid update schedule, then employees may feel as though they’re required to take technical debt on to ensure that the project makes it on time. Communicating openly with employees, being clear about expectations, and not setting expectations that are too high, can also avoid technical debt.

A strong culture of debt elimination can help a business, as it will encourage all employees throughout the company to perform the appropriate analysis and reduce their own risks. Time management is also critical: the better the time management of a company, the more time there is to fix any issues with technical debt.

Most companies don’t choose to have technical debt because they don’t want to do the work. They choose to have technical debt because they have neither the time nor the money to completely optimize a solution. If there’s a tremendous amount of technical debt, but no money available to resolve it, then the project may have been estimated incorrectly from the start.

Locating and Identifying Technical Debt

What if technical debt has to be addressed later on in the project, but it hasn’t yet been identified? This can happen if the strict controls outlined above haven’t yet been achieved. Before technical debt can be resolved, it needs to be found. This can also present complications for a business, because it’s not immediately obvious where the technical debt is, especially in a more complex system.

To find technical debt, code review is necessary. The software needs to be pulled apart layer by layer to identify any inefficiencies and reduce them, and whole modules may need to be overhauled and rewritten to keep them in line with the company’s ideal baseline.

Better business processes and thorough recordkeeping can drastically reduce the amount of time spent on technical debt. If technical debt is intentional and well-documented, it makes it far easier for the company to go back to the debt issues later on. Resolving technical debt can occasionally be an involved process, at which point another cost-benefit analysis will need to be completed.
 

Technical Debt and ROI: the Bottom Line

When no one is looking, technical debt happens. But it’s not inevitable in a project. If you control your project, keep better business processes, and foster a culture of “let’s fix it now,” you can reduce technical debt and improve your organization’s ROI.

With large projects and complex projects, it’s easy for technical debt to emerge. It’s also easy for technical debt to remain hidden. Technical debt isn’t something that most clients are looking for or asking about, and consequently it can be ignored quite often. Since technical debt starts at the beginning of a project and then begins to slowly escalate, it can be a major problem by the time it’s noticed.

But while technical debt can be reduced, it can never be fully eliminated. There will always be situations in which a business needs to push a product out even though it’s not fully optimized, or in which it may not be in a company’s best interests to spend the time developing a debt-free solution.

It may be time to audit your technical debt today. Are you following best practices?