Defining technical debt, how to reduce it and how to get rid of it
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:
Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organisations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.
Breaking down technical debt further, there are, broadly speaking, three different categories it can be classified into; naïve, unavoidable and strategic:
There are probably thousands of things which can cause an organisation to start accruing technical debt, but some of the most common are:
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…
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!
Get in touch today to discuss strategies to reduce your organisations technical debt...