Technical debt, sometimes called design or code debt, is a concept in software development that talks about the extra risks you accumulate when using code that’s easy to implement in the short term but you know isn’t the best solution for the long term.

The ‘debt’ is the additional time you’ll have to spend fixing these issues down the line, costing staffs time and rescources.

Just as with fiscal debt, Technical debt also earns interest the longer it goes ‘unpaid’ (fixed), making it that much harder to affect true Digital Transformations.

Consider a software developer, working hard on a part of the code base they’re designing. Any change they make in the code will likely have far reaching affects on other parts of the codebase or documentation. Changes that are necessary but not corrected can be considered ‘technical debt’, and, until the developer (or some other unlucky individual) pay it back, will continue to cause far reaching problems.

Whilst it’s mostly a coding term, it shouldn’t be hard to see how this concept can also be applied to other job roles or processes within an organisation.

This next paragraph won’t help you prevent or get rid of Technical debt but it’s quite interesting, so we’ve included it for you anyway… feel free to skip down to the next paragraph though.

The term ‘technical debt’ was first used by a man named Ward Cunningham (who actually developed the first ever Wiki).

When describing the concept for the first time back in ’92 he said:

Breaking down technical debt further, there are, broadly speaking, three different categories it can be classified into; naïve, unavoidable and strategic:

• Naïve – Technical debt caused by naivety typically occurs when protocols and governances aren’t followed or correctly applied. Hence, it could also be called negligent technical debt. The reasons this might occur are many and varied, unfamiliarity with protocols, rushed worked, odd naming conventions, etc, etc. This kind of debt (whilst not looking to disparage junior developers) does occur more at the junior software developer level… but even the most experienced of devs make mistakes things sometimes!
• Unavoidable – Unavoidable technical debt is caused when tools or processes get upgraded, resulting in more efficient ways of doing things. Whilst great, it does mean older processes may need upgrading to the new, achievable standards. Changes to the scope of a project without adjusting deadlines can also have the same result.
• Strategic – Strategic technical debt, as it sounds, is when a conscious decision is made to take on technical debt, perhaps to meet a deadline or perhaps because the financial cost of the debt is outweighed by a speedier finish to a project.

There are probably thousands of things which can cause an organisation to start accruing technical debt, but some of the most common are:

• Insufficient briefs at the start of a project often lead to technical debt, with unnecessary or incorrect solutions needing to be re-done. This can be exacerbated further with development starting before a brief is even fully scoped out, in a misguided attempt to save time.
• In ongoing developments or projects that are continuously improved, older solutions sometimes become sub-optimal, as better, more efficient, solutions are found. The technical debt occurs when you need to go back to fix these older elements.
• Pressure from upper management to get a project completed quickly often leads to a build-up of technical debt, with rushed, inferior, or unchecked code often making it into the final solution.
• If your organisation lacks strong governances or is simply unaware of the concept of technical debt, it becomes very easy to accrue it without ever realising.
• Having a sandbox to test solutions in before pushing them live is vital in preventing technical debt. Whilst a solution might look great in theory, it’s only when it’s tested in situ that all flaws are really revealed. Writing code ‘live’ without thorough testing is a great way to collect technical debt.
• If a solution is arrived at but not documented correctly, then the work and time required to retroactively document it can also be considered as technical debt.
• Technical debt is very common in organisations that suffer from a lack of collaboration, where data is siloed, and junior developers aren’t mentored correctly, instead just left to ‘figure things out’. Siloed data also means parallel development often occurs on different parts of a solution, with the duplicated work being the technical debt.

Technical debt isn’t always a bad thing if it lets you get to market faster than a competitor, but it does eventually need paying back, and that process can be painful. Avoiding as much technical debt in the first place is a lot easier in the long run…

• Technical Debt Isn’t A Dirty Word – (Or two words). If your staff are aware of technical debt, are encouraged to talk about it, and know what they can do can do to prevent it, then they’ll be that much more likely to find solutions to heading it off as they go.
• Good Governance – cloudThing are huge advocates for good governance. By taking the time to address possible outcomes before they occur, you’re heading off technical debt before it becomes an issue. Make time within your project for technical debt, schedule planning for it into your processes and make limiting Technical Debt a KPI that your developers can work towards.
• Don’t Run Before You Can Walk – Rushing, or leaping in, is the easiest and quickest way of accruing technical debt. Make sure projects are fully scoped out, plan ahead and above all involve your developers in every step of the process. Let them set realistic deadlines with you to avoid corners being cut to meet them. Resulting in technical debt.

Reducing existing technical debt is often a long, laborious process over going back over existing work and fixing issues.

It is something cloudThing have specialised in for a long time though and would be happy to advise you on.

You first need to understand what and where your technical debt is, normally achieved through collaborative discovery workshops with your developers.

Once you’ve identified as much of it as possible you need to develop a strategy to reduce the technical debt with incremental changes and you won’t be able to do everything all in one go. When defining that strategy, it’s important you set clear delivery goals with associated metrics and KPI reporting so that everyone has a clear picture of what they’re working towards.

Then… it’s a simple case of going after it!