What is Technical Debt and why should you care?

What is Technical Debt and why should you care?

The term 'Technical Debt' describes the ongoing technical burden of a hastily architected or poorly implemented piece of software. It describes the amount of work needed to be done on an existing codebase to complete further development. Basically, the greater the level of technical debt on a project, the greater the cost to implement a feature above the base feature cost.

What is Technical Debt?

Think of it this way, if you wanted to add a blog section to your website but couldn't because during launch you decided that you would for-go using a database in favour of static content, then getting a database setup and writing code to interface with that database would be a significant existing debt, one that you would have to pay before you could implement the new blog section.

However, often technical debt isn't as pronounced as this; usually it comes in the form of a partially-implemented feature here, a // TODO comment there, a hardcoded ID, an architectural assumption or a plain and simple shortcut in order to meet a deadline. Individually these things are not show stoppers, but over time as more of these appear in the codebase, the technical debt increases significantly. You could relate this back to financial debt and the concept of incurring interest on your debt.

Like financial debt, technical debt has to be paid back at some point. The longer you leave your technical debt, the more of it there will be to repay and therefore the more work it will take to complete.

Why does Technical Debt exist? Can it be avoided?

Technical Debt comes from the day to day development of a piece of software by one or more developers. Depending on the training, talent and experience of the developer(s) working on the project the amount of debt incurred will vary.

If developers are all on the same page and implement a feature fully in an architecturally sound, forward-thinking way, then technical debt is likely to be minimised. However that rarely happens in the real world, especially with non-development-centric issues like business and marketing timing applying pressure to complete features in an expedient manner. That's when debt is accrued in order to reduce the time needed to produce a working piece of software.

Technical Debt most often manifests as technical constraints when modifying the software to add or change features, however it can also manifest as code readability (the inability for developers to accurately guage what a piece of code is doing) and information siloing (only one developer knowing details about a piece of the project). These are considered technical debt because they are obstacles which must be overcome before features may be changed or added to a project.

What is the impact of Technical Debt on the business?

The primary result of accruing too much technical debt is that tasks will take much longer to complete than they otherwise should. And of course each task performed on a high-debt codebase introduces even more debt, which is clearly bad.

The second result of accruing too much technical debt is complexity of the codebase. A codebase with a high level of technical debt is one that is large and complicated beyond a reasonable level that it's features should require, which indirectly causes more debt through the inability for new developers to gather information and understanding about the codebase.

The impact of both results is time, and therefore money. The cost to maintain or improve a codebase with significant technical debt is substantially higher than an equivalent project with no technical debt. That statement is so simple is should be obvious, but it needed to be stated.

What can be done about existing Technical Debt?

The only thing that can be done (without scrapping the whole project), you need to pay back the debt. In practical terms, this means working on fixing or removing the code within the codebase which is casuing the debt. This process will typically mean targetted rounds of refactoring and regression testing to ensure that the end-user quality of the software isn't impacted through the reduction of the technical debt.

It's important to realise that the goal of those refactoring rounds is to reduce the debt, which means rewriting parts (or all) of a feature in order to make it debt-free and future-proof. It's critical that the right decisions are made during this process in order to avoid creating more debt, which of course would only increase the debt further.