Technical debt (also known as design or code debt) – is it really that bad, and is it worth the effort? Although the word “debt” has a negative connotation, business people understand that debt, when properly managed, can even be beneficial. The main thing is to assess it and build the right strategy. The same goes for technical debt: first, you need to identify it, evaluate its impact on the software being developed, and schedule sessions to eliminate it gradually. The good news is that there are automated tools you can use for measuring and reducing technical debt. The bad news is that teams often ignore the issues they find, causing them to get out of control. 

Technical debt itself isn’t that problematic in the short term — your software may work fine. But in the long run, having that kind of debt can be a ticking time bomb for a business. So, how can you manage and reduce technical debt?

Decoding technical debt – an inside look

What is technical debt and why does it occur?

Essentially, technical debt is necessary changes in the code itself and the software architecture as a whole, postponed until later. The problem is that this “later” may not come, which may increase the cost of maintaining a poorly designed system. How do you know that the source code is bad? Not only is it software in which previously undetected bugs keep popping up, but also an application whose functionality expansion often leads to a complete rewrite of previously completed parts.

There are multiple reasons why technical debt occurs. Let’s have a look at the main ones:

• This was a clear business decision to get the product to market as quickly as possible. However, it’s crucial for the decision maker to bear in mind that the next version of such a product may undergo a complete revamp from scratch.
• Development processes are not mature, team members are unfamiliar with coding standards to adhere to, or there is no technical decision maker on the team. The latter may lead to very poor architectural design and implementation.
• The team simply does not adhere to the company’s coding standards, and the technical manager is either absent or serves only as a nominal leader with no real influence over other team members.

Third-party libraries used in the project have been significantly modified or the project environment has undergone crucial updates. This type of technical debt is called environmental debt.

How to measure technical debt?

The most popular method for measuring technical debt is SQALE (Software Quality Assessment Based on Life Cycle Expectations). Your codebase will be rated on an alphabetical scale from A to E, with A representing the highest quality rating.

To help you decide which problems to fix and when you can use the SQALE pyramid illustrating the distribution of code debt based on its impact on application stability. The lower the level, the shorter the term causing problems due to technical debt. For example, if you have testability or reliability issues, you may expect functionality to be implemented incorrectly. Whereas higher levels show tech debt issues that may affect you in the future, such as during the maintenance phase.

For example, to ensure the reliability of your code, it’s essential, at the very least, to address all issues related to testability and reliability. If your goal is to cut down on future maintenance costs, you also need to handle problems related to changeability, efficiency, security, and maintainability.

Security issues as a crucial part of tech debt

Given the high focus on cybersecurity these days, it makes sense to address security issues as soon as they are discovered. The OWASP Top 10 document is adopted by a global community as a software security standard. This document represents the most important security risks for both web and mobile applications. It should be noted that the OWASP Top 10 is updated over time.  On the one hand, modern development frameworks cover known problems, leaving little room for developers to write insecure code., And, on the other hand, cybercriminals come up with new ways to hack systems. Thus, to ensure that your development follows the latest industry standards, remember to regularly check that the OWASP ruleset implemented in your project is up to date.

OWASP Mobile Top 10 changes in 2016-2024 are presented in the table below:

Dealing with technical debt

To keep your project moving in the right direction and reduce technical debt, consider the following steps:

1. Implement coding standards across the organization, not just a specific project. The most effective way is to create your own guidelines based on best practices accepted by the global development community.
2. Choose a suitable development methodology and plan releases. Nowadays, most projects are developed using Agile frameworks (such as SCRUM, Kanban, Lean, SAFe, etc.). However, some types of projects may require a more traditional Waterfall.
3. Automate the development process to help your team stay on track. That is, you will need a set of tools that seamlessly integrate into one ecosystem, ensuring transparency of the progress and quality of the entire project.
4. Involve DevOps to set up a Continuous Integration / Continuous Delivery (CI/CD) process, including the automated code review step. Adopting internal coding standards doesn’t guarantee that developers will regularly follow them.
5. Plan refactoring sprints in advance. Ideally, short-term technical debt issues should be resolved before the change set is committed to a version control system (such as GitHub). While long-term issues usually require more effort to resolve and more thorough regression testing after such fixes. Therefore, you will need additional iterations to refactor.

Without getting too deep into release planning management, let’s use the example of three-month releases that deliver functionality incrementally every two-week sprint. With these assumptions in mind, the illustrated planning below may be helpful:

With six sprints per release, it’s important to remember the feature freeze phase. Usually the last sprint is used to stabilize the software, meaning no new feature is implemented and the team focuses on fixing bugs. Some low-risk technical debt issues can also be resolved during the last sprint. However, the technical leader should evaluate whether these fixes are risky or not.

If your software requires more significant changes or issues with a high risk of technical debt in the backlog, it makes sense to schedule an additional refactoring sprint at the beginning of the next release development. This approach will give your team the necessary time to implement changes and run regression tests to ensure that no functionality has been affected.

Reducing technical debt with the help of DevOps

What DevOps activities are most important for reducing technical debt? First of all, a DevOps specialist is the very person who is responsible for setting up the CI/CD process. Without continuous integration, you won’t be able to ensure the stability of your software. In addition, a DevOps performs the following responsibilities:

1. Deploying an appropriate static code analysis tool and configuring it as an additional step in the CI process. This way, code reviews can be performed automatically without the possibility of skipping them, ensuring that a change set of low quality will be rejected by the CI server and never be committed in version control.
2. Deploying and configuring the version control system, creating the necessary branches (for example, development and release branches), and setting policies for review requests.
3. Monitoring for updates to third-party components that may affect the software being developed.
4. Checking possible vulnerabilities in the tools used in the project.
5. Advising the team on which architectural patterns and third-party services (e.g., Database as a Service) are most relevant for continued maintenance and monitoring.
6. Consulting the project manager and the customer on which hosting/cloud provider is most suitable for the solution being developed.
7. Setting up the necessary project environments depending on their purpose. For example, DEV  for developers, TEST  for internal QA team, STAGE for user acceptance testing, and PROD  for release. Static analysis quality gates can be configured differently for different environments. Depending on the team’s policy, the DEV environment may be used by the team to speed up synchronization with each other, and therefore, some new technical debt issues may be deployed to it. The higher the environment (DEV to PROD), the higher the quality of the deployed code should be.

How to reduce technical debt with static code analysis tools

Automated code analysis tools can help reduce technical debt and even eliminate it. They address the question of how to measure tech debt and provide recommendations for creating quality code, which is also crucial for security. Among the many platforms that provide code quality inspection, there are two products worth considering: SonarQube and CAST Imaging.

Both SonarQube and CAST Imaging provide static code analysis. They can detect design errors, identify potential problems due to the misuse of certain libraries and expressions, find code smells (namely clear violations of design/coding principles), and detect duplicates in the code base, as well as security vulnerabilities. In addition, both platforms can analyze the result of unit test execution and calculate code coverage.

CAST Imaging provides an in-depth analysis of an architectural design. Using CAST Advisors, software developers can modernize their applications and easily move them to the cloud. At the same time, SonarQube is more flexible and can be customized even for a specific branch of the project. The latter allows teams to have different settings for code quality analysis depending on the stage of development. For example, at the ongoing development stage, the team may focus on short-term issues of technology debt, leaving the long-term issues of tech debt for the refactoring phase.

Using one of these tools can help you with technical debt management.

Let’s compare these platforms.

How technical debt reduction affects the QA team

Taking action to resolve technical debt may seem like too much extra effort. However, it is not. Keeping technical debt at an appropriate level will reduce not only the subsequent maintenance costs, but also the workload of the QA team in the current development cycle.

Considering that testability is one of the components of technical debt, we can confidently say that improving testability and code coverage can help the QA team in their daily work. When developers promptly address short-term technical debt issues and maintain a code coverage of at least 60%, the QA team can focus on testing new features, usability testing, and verifying bug fixes. Moreover, automatically running unit and integration tests frees up the time of the QA engineer who would otherwise have to perform regression testing manually.

When it makes sense to ignore technology debt

Making code academically beautiful is always a pleasure. However, sometimes you can leave everything as is and not pay much attention to the growing technical debt. This makes sense if:

• You are developing a PoC (Proof of Concept) or prototyping some features.
• Time to market is critical, so you are willing to sacrifice code quality.
• You are dealing with a legacy code base that is scheduled to be completely rewritten in the near future.

All of these cases have one important thing in common: this codebase (be it PoC or legacy software) will be thrown away in the near future. Even where time to market takes precedence over code quality, you should keep in mind that you will probably find yourself rewriting the entire product from scratch when gearing up for the next major version. Nevertheless, it is strongly advised to review and address security issues regardless of your future release plans, as a system breach could wreck your business.

Conclusion

Whether you have legacy software or start your own development from the ground up, you need to plan and provide for many things to ensure the project runs smoothly and to maintain the product’s stability. Timspark specialists have extensive experience in both taking over software maintenance and launching new projects. For legacy software, we first conduct a technical assessment and provide you with a plan on how to reduce technical debt. In new projects, we have boilerplate approaches to quickly and inexpensively deploy the required environments with all the necessary project tools for effective software quality management.

References

1. The SQALE Pyramid: A powerful indicator. sqale.org, 2013. 
2. OWASP Top Ten.  OWASP Foundation, Inc., 2023. 
3. OWASP Mobile Top 10. OWASP Foundation, Inc., 2024.  
4. Prevent, reduce, and manage code-level technical debt. SonarSource SA, 2024.
5. CAST Imaging now features automated advice for accelerating application modernization and cloud migration. CAST Software, 2023.