technical debt: basic beginner's guide

What is technical debt?

Technical debt, also known as design or code debt; is the future cost of rework you will need to do at a later point in time within software development because priority was placed on speed, quick fix patches, or releases instead of complete or finished code. It is the debt the company will have to pay in the form of time, money, resources, or loss of business for favoring speed over quality. 

Tech debt is used and defined to include a wide variety of different possibilities with what is wrong with your code. Ranging from legacy code, missing or incomplete documentation, bugs, etc. 

The concept is borrowed from financial debt where one is loaned money to buy something one wants now when you do not have the money for it and will have to pay for it later, with interest. 

We all know interest can be high and may always increase! 

Arguably technical debt, similar to financial debt, may not be a bad thing and can be used to progress a project forward. Still, eliminating technical debt from the start of a project is recommended because it creates software entropy if it is not dealt with in a decent amount of time. 

Thinking of tech debt as a necessary evil to move things forward generally results in insufficient prioritization of the necessary tasks to correct and fix it. 

As one part of the codebase is changed, there is often a need to make calculated updates to other parts of the codebase or adjust your code accordingly to other areas of the code or documentation. If you do not make the necessary changes now, those issues will continue to accrue interest until they are paid or fixed. 

In agile

Agile development depends on speed and software features need to be functional in continuous development. Prioritizing speed and delivery over quality assurance and best practices. 

Implementing quick sprints with short deadlines means that code may not get the necessary review needed and cause low-quality code. Often, they prefer new features over bug fixes and other needed fixes. 

Even though agiles' main purpose is to increase forward motion by speed, the lack of tackling bug fixes eventually reduces forward motion as the issues accumulate. 

In scrum

Scrum is an agile project management framework that is supposed to help structure and manage teams, typically through a product owner, Scrum Master and developers with different responsibilities. The way Scrum is structured, removing and eradicating technical debt is supposed to be built into the next sprint. 

Some of the issues that arise are who is responsible for identifying, measuring and dealing with tech debt. 

What causes technical debt?

This typically means software development is making choices in coding which are not up to the recommended or needed standards when it is moved to production. There are some amounts of technical debt that are basically inevitable but can be greatly reduced by using a code reviewer. 

They include:

Ongoing development

With companies and code constantly changing, they operate in long or continuous periods of project improvements that over time make old solutions inefficient. 

Modern software applications generally include several programming languages, development frameworks, and libraries, among other external resources. The support, or lack thereof, can greatly impact those applications and their effectiveness. 

Lack of definition

This is when development begins before any designing occurs. If you do not clarify or establish a baseline of what constitutes technical debt or if requirements are still being established during the dev cycle; then what was created at the start may not be what is needed by the end of the project. 

Business pressure

With the constant pressure of businesses trying to stay afloat and remain competitive and financially prosperous, they may release or produce something which is not quite ready yet in order to get it out there or be first in the field. You see this with website and app launches that crash or have glaring glitches and usability issues. 

With business pressure remaining constant, updating and fixing these problems may always remain in the development backlog. 

Lack of technical knowledge or comprehension

Even really savvy business people can be unaware of tech debt and blind to the complications which arise as they strive to push out and release update after update while focusing on the product and bottom line. 

Coupling of software modules 

Where the degree of interdependence between software functions is not independent of interchangeable modules and is unable to accommodate changing business demands. 

The lack of a test or validation suite

Allows swift and unsafe jerry-rigged bug fixes without proper test cases to test the software program and ensure it operates as expected. 

Lack of collaboration

Where vital knowledge is siloed between departments, teams, and individuals. This causes business productivity to diminish through a lack of communication, training, and mentoring. 

Simultaneous development

Within many organizations, development teams may be working on various branches at the same time leading to a lack of code cohesion when the finished product is merged into a single code base. The more code creation occurs in siloes, the more technical debt emerges. 

Delayed code refactoring

As the development requirements change for a project, the other previous code creation may become obsolete or hard to update for future coding or business needs. As refactoring is pushed back the bigger the tech debt becomes. 

No clear standards or alignment

When business best practices, standards, software frameworks, and existing technology are disregarded. Ultimately, the standards for code integration will happen and the longer the wait, the more it will cost in the future. 

Insufficient developer knowledge 

The developer doesn't have the know-how on creating and executing elegant, clean code. 

Outsourced software developers

When resources are outsourced to third-party developers it sometimes culminates in the in-house development team needing to refactor the code delivered. 

Defective leadership

The communication of commands which are distributed from the top down and is not clearly thought out or contemplated before being executed. 

Last minute changes

When the project is almost completed or close to completion and new requirements are provided before a tight deadline and there is no time, resources or budget to test and collect the implications of the adjustments. Here the main goal is to ship the product with the additional changes in hopes that everything works correctly. 

Types of technical debt

While there is a wide variety of technical debt types and definitions, they can ultimately be divided into three categories: unintentional, intentional, and environmental technical debt. 

Intentional technical debt can be defined as decisions one makes knowingly at the time and may or may not have the intention of going back and refactoring the code. 

The company is choosing bad, or dirty code, which may result in code security risks, unstable code, intermittent, or terrible performance, and user experience. Though not optimal, knowing about these issues allows the team to document, measure, and update when needed. 

Unintentional technical debt may be defined as the unconscious creation of poor or sloppy coding that is promoted to production without proper testing and review.

Other factors, such as added or increased complexity within a project where the developers are unaware of the bugs they are inadvertently adding to their code. This kind of technical debt is dangerous because some issues can be unknown for a while. 

Environmental technical debt is defined as debt that has increased over time without any active development from within the code itself. 

This may be caused by other external factors such as an operating system is updated, resulting in something breaking or not working properly. Third-party API updates that break the connection or codebase libraries that bring in unwanted user issues. 

Security updates or patches may stop an application from functioning as it should. Even if the original code is good and works, the tech debt will gradually increase over time. 

The types of technical debt may be further broken down based on the particular classification of essential differentiators such as 

• Architecture Debt 
• Build Debt 
• Code Debt 
• Defect Debt 
• Design Debt 
• Documentation Debt 
• Infrastructure Debt 
• People Debt 
• Process Debt 
• Requirement Debt 
• Service Debt 
• Test Automation Debt 
• Test Debt

Is technical debt bad?

While some say that it is not necessarily bad, it is not something you want to collect if you can help it. Accepting a little technical debt for the short term when time is against you on a product release can be justifiable, or when vital software updates need to be shipped immediately.

Technical debt is bad and becomes a problem when it is left alone and not corrected in a timely fashion. The build-up will continue to pile up and eventually cascade into an avalanche. 

However, most tech debt produced today is due to poorly written code. 

This is a shame because no developer wants to write bad code and be inefficient in their level of programming expertise. 

Technical debt may only be considered good if you have the intention of paying it back and removing the debt completely. Anything outside of that is truly considered bad. 

Can you reduce technical debt?

There are several proactive ways to reduce technical debt. 

Automate Testing to eliminate technical debt. 

Manually testing code for quality assurance can be time-consuming and inefficient. 

Using automated testing tools, like SonarQube, can reduce or eliminate technical debt. The use of automated debugging cycles and other operations which scan for code problems every time the module is updated. 

SonarQube provides continuous inspection of code quality to perform automatic reviews with static analysis of code to detect bugs, code smells, duplicates, coverage, and security vulnerabilities in multiple programming languages. 

Refactoring source code

Refactoring can be a different way to deal with technical debt by taking advantage of the source code's quality while leaving the expected behavior of the code alone. Refactoring is meant to correct poor code quality and can be fixed with automated testing tools. 

However, lack of experience or incompetence may also play a part, which should be dealt with on a personal basis. Either more education or training may be required. 

Use coding best practices

Companies and organizations should establish coding standards internally that developers are to follow and execute. When developers are on the same page regarding code etiquette and standards, this assists in eliminating technical debt from the beginning. 

Project structure

Creating better project structures through project management tools or monitoring code troubles and fixing them as soon as possible within projects will reduce the debt. Prioritize projects and the structure to support your timeline and workflow. 

As mentioned earlier, using code quality, security and analysis tools can greatly decrease the amount of technical debt you and your company will have to deal with at a later point in time.

How do you find and manage technical debt? 

Probably one of the best, and easiest, ways of finding and managing technical debt is to use code metrics as a base to measure technical debt. There are many methods available to provide that data. 

Code coverage 

Code coverage is the percentage of your source code that is tested to a certain degree when a program is executed on specific test suites. These are rules and requirements which must be met with the test suite (program subroutines or statements called during the test). 

As more and more code is added, you will want to make sure the coverage remains consistent and does not slowly or significantly decrease. 

Cyclomatic complexity

Cyclomatic complexity is a quantified software metric used to show the complexity of a program by analyzing the independent paths against the total lines of code. The more independent divergent paths, the higher the cyclomatic complexity, and thus the more difficult the source is for maintainability. 

SQALE-Rating

SQALE-Rating is a method to support assessing the quality of source code as a direct correlation with technical debt over the project. Typically based on an alphabetical scale from A to E with A being the best quality score. 

Rule violations

Rule violations are calculated by the established set of code standards that are violated or broken. Typically grouped into categories based on the severity of the violation. 

Bugs

Counting the number of bugs in your software and monitoring critical issues is a good option to evaluate technical debt. (The more bugs found, the more technical debt increases). 

Cost of delay

The measurement “cost of delay” is a framework that helps businesses quantify the economic value of finishing a project sooner instead of later based on prioritization. The goal is to provide transparency on how much time teams lose that is attributed to technical debt. 

Conclusion

While some technical debt may be inevitable, most of it surely can be preventable. 

Getting ahead of it before it becomes a problem later down the road is one way to ensure that you, your operations, your business, and most importantly, your code, are clean and debt-free moving forward. 

While there are numerous tools available in the market which can be used to clean and prevent technical debt, we highly encourage the use of our free Lint IDE tool. Completely free and covering several programming languages, SonarLint provides real-time feedback evaluating over 5,000 rules covering a wide range of issues. 

Utilizing language-specific analysis to detect bugs, code smells, and security vulnerabilities all the while maintaining the latest language standards. This free tool for your IDE contains a large ruleset spanning reliability, maintainability, readability, security, quality and so much more.