Most companies are aware that their IT solutions contain technical debt. However it tends not to be a high priority to fix it. There tends to always be pressure to add new features or work on user experience over dealing with technical debt. This can be a mistake. Over time technical debt can mean that you have actually got less done in a given time than if you had fixed the technical debt first. Clearly this is a problem, so how do we deal with it.
First lets define technical debt. Technical debt is any detail of your project which has negative value, this could be poor structure, inefficient code or even poor documentation. Anything built in to a project which makes it hard to change, improve or extend can be considered as technical debt.
| IT Project Detail | Visible | Invisible | 
| Positive Value | Feature | Architecture | 
| Negative Value | Bug | Technical Debt | 
The first thing to do is to ensure that you don’t accumulate technical debt unnecessarily. Note the use of the word unnecessarily, this is because sometime there can be reasons to acquire some technical debt. Perhaps the work being done is a prototype or proof of concept. In that case some technical debt may be acceptable so long as it is not allowed to creep into the final design. When deciding whether potential technical debt should be accepted the following diagram may be useful.
| Nature of Technical Debt | Accidental | Deliberate | 
| Considered | Prototyping (Learning) | Business Tradeoff (Judgement) | 
| Reckless | Poor Code (Inexperience / Incompetence) | Corner Cutting (Laziness) | 
As evidenced by the diagram not all technical debt is equal and not all is acceptable. Reckless technical debt should be strongly discouraged as it is highly avoidable. Other technical debt may be an acceptable trade off.
Even technical debt which has been prudently allowed to occur should be paid off when possible. But how should you decide where to start? One way to decide is to start with the low hanging fruit. First list all known sources of technical debt. Then estimate the cost to fix and divide this by how much each item is costing you per month. This tells you how many months it would take to break even on a particular piece of technical debt. You can then prioritise those with the quickest payback. This should then free up time which you can invest to attend to more technical debt. This should cause a virtuous circle of improvement. This way your total amount of technical debt can be kept to an acceptable minimum.
The easiest way to conduct these calculations is via a spreadsheet. A simple easy to use technical debt calculator can be found on my Github page. Best of luck with reducing your technical debt.