What is technical debt?

When a project needs to be completed quickly, sometimes the speed of delivery takes top priority. This is the type of situation in which the concept of “technical debt” can arise. Like financial debt, technical debt can be a useful tool when working with limited resources, but it must be repaid in the future.

Technical debt definition

Technical debt is also sometimes known as design debt or code debt. It refers to a situation when a development team prioritizes delivery date over design. While the project is made functional at the time, it’s with the stipulation that the design or code will need to be perfected later on. The debt itself will vary depending on the project. It could refer to known bugs in the system, missing documentation, or other issues that can be fixed in the future.

The phrase was first coined by Ward Cunningham, a software developer who helped co-write the Agile Manifesto. He used the metaphor of “technical debt” as a way to explain the idea that rushing the delivery of imperfect software might be necessary at times, but that you would have to repay the technical loan by going back and refactoring the software with greater knowledge in the future.

Technical debt examples

Coding is just one piece of the puzzle when it comes to technical debt in software development. Multiple areas could fall under this umbrella, including the following:

• Design debt

• Architecture debt

• Code debt

• Documentation debt

• Testing debt

• Process debt

As you can see, technical debt examples could refer to any part of the finished project, not just the coding. The design could be kept intentionally basic, while a process may be kept generic until the finer points can be sorted out.

What is the purpose of technical debt in software development?

Developers might use technical debt as a catchall phrase for any quick fix. Its purpose is clear: it’s a simple tool for pushing forward a project. This might involve using more basic code that developers know will need to be reworked, but with the benefit of achieving quick gains in the here and now.

What’s important to realize is that intentional technical debt doesn’t include mistakes like sloppy or error-ridden code. It’s a purposeful strategy used by developers to prioritize delivery deadlines or client-facing value over more technical issues. Intentional technical debt does the job as well as it can with limited resources. By contrast, unintentional debt results from a rushed job and will have more significant consequences when the mess needs to be cleaned up. Ideally, technical debt is created with a clear repayment strategy in mind. 

What challenges does technical debt present?

Like any debt, technical debt must be repaid. Occasionally, this can have long-term consequences. As a project matures, the imperfect code can become increasingly problematic. Because shortcuts have been written into the code to achieve a goal, it means there may be problems down the line. These shortcuts will have to be rewritten for the program to work at its best. Unintentional technical debt presents more significant challenges than carefully planned, strategic shortcuts.

When should a company use technical debt?

We’ve already mentioned above that technical debt can sometimes be used as a strategic tool. In a competitive marketplace, software companies can often be under intense time pressures to launch new programs. Although technical debt may mean that a product isn’t as fine tuned and agile as possible, it can be necessary for circumstances when time is of the essence. The development team can make a strategic choice to take the shortcut and pay the debt later.

When should a company avoid technical debt?

Taking the road of technical debt isn’t the best strategy for all teams or projects. If a team is working with a documentation-driven structure, skimping on this necessary documentation can be unacceptable. Creating technical debt could lead to tricky difficulties in the future, and there may never be time to solve the problems in a fast-paced working environment. If the team believes that repaying the debt will be problematic, it’s best to avoid it in the first place.

Technical debt management principles

Sometimes technical debt is unavoidable. Like financial debt, it’s essential to repay it as quickly as possible. If a company already has outstanding technical debt, the first order of business should be to devise a repayment strategy.

Because technical debt is caused by weak code, the sooner it’s fixed, the better. Otherwise, the software could suffer consequences in future development, and the last thing you want is for customers to discover faults before you’re able to fix them. Sit down with the team to create a concrete technical debt management plan. It can be challenging to fix the code all at once, particularly when you’re working on other projects. Chip away at the debt with a manageable schedule, allowing the team to rework the code in smaller pieces.

Is technical debt ever worth it?

Bottom line: technical debt is a strategy that values a short-term fix over long-term perfection. In some cases, getting a new fintech product to market is more important than fixing every bug. When there’s a serious time-crunch, it can make sense for some development teams. However, because it must be repaid, it’s worth keeping the time and costs in mind before deciding to take on technical debt. 

We can help

GoCardless helps you automate payment collection, cutting down on the amount of admin your team needs to deal with when chasing invoices. Find out how GoCardless can help you with ad hoc payments or recurring payments.