Technical Debt is a term widely used in industry but what does it mean? In this blog we’ll answer the question “What is Technical Debt?”, discuss the different types of Technical Debt, and some solutions to help you reduce your organisation’s Technical Debt.

So, what is Technical Debt?

Technical (or Tech) Debt is the result of actions taken to increase the speed of deployment of technology solutions. The way technical debt is accrued is when you take a shortcut or take some other action to deliver your product sooner than you otherwise would at the cost of having to fix bugs or refactor inefficient code at a later date – it’s essentially a result of the “build now, fix later” mentality.

But why do we call it debt? Well, another way of thinking about Tech Debt is likening it to Financial Debt. With financial debt, you borrow money to enhance your current position at the cost of a more expensive repayment at some later date.

Similarly, with Technical Debt, you take some shortcut or time-saving choice to enhance your current position (being able to deliver sooner), at the cost of having to spend more time to fix and refactor in the long run.

And just like with financial debt, where you have to repay interest over time and the interest increases the longer the debt is outstanding, the longer you leave technical debt, the more “interest” you have to pay on it, as the resolution for the initial shortcut becomes more and more complicated and time-consuming to fix.

“With borrowed money, you can do something sooner than you might otherwise, but then until you pay back that money, you’ll be paying interest. I thought borrowing money was a good idea, I thought that rushing software out the door to get some experience with it was a good idea, but that of course, you would eventually go back and as you learned things about that software you would repay that loan by refactoring the program to reflect your experience as you acquired it.” – Ward Cunningham, Debt Metaphor.

Common Causes of Technical Debt

Now we understand what technical debt is, we can start looking at some ways in which companies accrue technical debt into their systems.

Code Shortcuts:

Probably the most common cause of technical debt is when developers take shortcuts. As deadlines approach, it becomes more and more likely that a developer will have to take a shortcut to ensure that the deadline is met.

Shortcuts usually lead to code that, whilst functional, isn’t scalable, modular, or readable, all of which are a source of debt, as they make future developments harder.

The solution? Making sure there is open dialogue between developers and project leaders to ensure that the deadlines given are reasonable and achievable by the development team. The development team then needs to continually communicate throughout the development cycle to inform people if the project is falling behind so that more resources can be allocated if necessary.

Project leaders also need to ensure that there is a concrete development roadmap for the development team to stick to so that they are able to measure their progress and self-inspect themselves to guarantee they deliver on schedule.

Lack of Proper Documentation:

Another key step that development teams often look over during the development lifecycle is the creation and maintenance of proper documentation. Having a complete and up-to-date set of documentation for your code bases makes a huge difference to the speed at which future developments can be made.

As people come and go, it is vital that knowledge is not lost when individuals leave the organisation, otherwise, you can get to the stage where nobody knows how anything works anymore – which needless to say is not good!

To prevent this, a good practice would be to make sure that either during or just after each development sprint there is a dedicated time frame for writing product documentation, and that this documentation is considered as part of the deliverables for the project.

This way, developers have dedicated time which does not infringe on their development time to spend properly curating code base documentation every time there is a new feature, keeping the code base continually up to date.

Rushed Testing and QA:

In a waterfall environment, if development time overruns, then the first thing that gets cut is the time dedicated to testing and quality assurance. The testing and QA stage of the software development lifecycle is one of, if not the most important, as it ensures that the code produced meets the requirements, doesn’t have any abnormal behaviour, and hasn’t introduced any vulnerabilities into the platform. If this stage is skipped, then faulty code may be added to the code base, which may affect user experience, or the functionality of future code which may be added.

To ensure that testing stages never have to be rushed or skipped, an agile development approach should be taken. In an agile approach, code is tested, and peer-reviewed simultaneously with development, this way, all code that has been produced has been tested, so no faulty code will ever be added to the code base.

Technical Debt: Good or Bad?

So far technical debt sounds like something we should avoid at all costs, right? Well, yes and no. It is important to be continually reducing your technical debt to avoid having to invest massive amounts of time further down the line, but the act of “taking out” tech debt can actually be very useful – it just depends on how you use it.

Technical Debt isn’t always a bad thing.

When used in the correct manner, technical debt can be a powerful tool in a company’s arsenal. Just like taking out a loan to buy into a profitable market, technical debt can be used as a tool to pounce on, or even create market trends before it’s too late.

Many industries are experiencing the “ship or sink” nature of the modern business environment, and technical debt can be utilised as a tool to stay ahead of competitors and establish a market advantage by getting your product to market before anyone else – when now or never deadlines have to be made, technical debt can be the difference between success, and failure.

The debt always comes due.

Whilst technical debt can be used as a strategic decision, it must be dealt with in a timely manner. The longer it is left “unpaid” the more damaging it becomes, from poor performance to increased security risks, technical debt will always have some impact on your software.

Moreover, if your system is already experiencing technical debt, then adding more on top will only serve to make it even harder to resolve, making it more likely that you need to take out more debt, and so on in a vicious cycle of never-ending technical debt.

Different types of Technical Debt

In 2007, Steve McConnell introduced his idea about the two different types of technical debt: intentional, and unintentional. Intentional Technical Debt is a conscious, and strategic tool used by businesses to gain some advantage, whereas Un-Intentional Technical Debt is, as McConnell put “the non-strategic result of doing a poor job.”

Expanding upon this idea, in 2009, Martin Fowler publicised the idea of the Technical Debt Quadrant: To decide whether technical debt is acceptable or not, we need to inspect it to see where it lies on the quadrant. Prudent debt can, as discussed, be very helpful to organisations, and when the situation deems fit, Intentional/Prudent debt can be preferable. Unintentional/Prudent debt isn’t preferable, but is in most cases acceptable, as it shows a level of maturity within the development team to be able to self-analyse and learn from their mistakes. Reckless debt on the other hand is almost always unacceptable, as it shows a lack of strategy and maturity within the development team, which will rarely lead to long-term success.