Technical debt is when you proceed with a technical solution that is not 100% ideal and hasn't been wholly finessed because of your current project constraints. It allows you to roll out a solution to deliver faster results, whilst understanding that you will likely need to improve or revise or solution later on. It is sometimes called design debt or code debt.

Some real-world examples of tech debt include adding a workaround into a piece of code rather than rewriting it completely, or implementing an automation solution that will give your organisation efficient results while you are working on a longer-term solution. 

To extend the metaphor a little further, if an IT department has been making adjustments and workarounds to software code without refactoring to make the code straightforward and easy to modify, then adding a new feature might take them five days instead of three. Those two days are technical debt. Refactoring or fixing the code may take four days, which seems excessive if you are only adding one new feature, but if you are adding three or more, it becomes worthwhile.

The Causes

Organisational challenges that lead to technical debt include:

• Insufficient up-front understanding of the requirements
• Time pressure to release the solution quickly
• Inability to test the solution
• Lack of documentation
• Poor collaboration and lack of knowledge sharing within the organisation
• Solutions being developed in parallel in different parts of the business, that then need to be married up later on.

In the longer term, if technical debt is not "repaid" or the short term solution redesigned, then it can lead to software entropy, whereas the system is modified, the weakness is magnified and becomes a more significant issue.

Types of Tech Debt

Tech debt generally falls into two categories - it is a considered choice, or it is unintentional. If it is considered, the organisation is usually deciding to prioritise the immediate value that will be delivered by launching the solution immediately versus taking longer to craft the perfect solution. If the tech debt is unintentional, it is generally related to a lack of knowledge or understanding of the processes or the implications of a decision.

Martin Fowler, who is considered an expert in Enterprise Applications, broke this down further into four quadrants:

Tech Debt in Healthcare

In healthcare, tech debt is relatively common for several reasons. Budgets are often limited, which can lead to workarounds rather than longer-term strategic investments in improved systems. Additionally, there are many legacy systems in place which are clunky and difficult to integrate with newer technologies. Also, events such as coronavirus can lead to a demand for a quick solution to an unexpected challenge.