Managing technical debt is a big issue for most companies.
In the previous post I outlined exactly what is technical debt, how it’s created and why it’s worse than financial debt/.
Today I’ll talk about about managing technical debt from the view point of solutions and practical steps.
We will outline and suggest practical examples and ideas you can implement today so you can start managing your technical debt.
Let’s dive into it.

Managing Technical Debt issues – Identify and prioritize

The first step in managing technical debt is to identify where the biggest issues are. While this might sound obvious, I’m not talking about where the worst code lives. You should find the most impactful issues to the business. Many times technical people look from tech perspective and not from a business perspective.
This means, you need to ask questions, ideally a business stake-holder the product owner, or yourself if you know a lot about the business.

  • What is slowing us down the most today?
  • Where is our biggest bottleneck today? Where is our biggest slowdowns
  • How can we impact business the most? Sales? Improving Customer Service?
  • What about your interactions with Tech & IT frustrate you the most?

As such we should identify what system would make the most significant impact.
Try to find review all the current Tech issues you have an rank them according to priority.
Make a list of all issues you have while thinking about the business impact first.

Tech Debt Issue Lists

When you’re writing out the list, try to be as detailed as possible. This means , change architecture, replace infrastructure, are not detailed enough.
You want to strive to create a detailed list, that can be easily converted into work items / Jira items / etc:
i.e. something like re-factor / re-write order processing module. is 3000 lines long, should be broken down and re-written. many functions such as calculate price, has too many flows and is over-complex. Remove duplicate code and cleanup

is much better.

Cost Evaluation

As you’re writing out your debt list, either while or after, review it and find a way to attach a cost to each item.
You can use any scale you want, such as Jira points, days of work, dollar cost, etc.
However it’s important as that is the second part of the tech prioritization.

After you’ve complied the list, you should have a list of business impact first, cost second analysis.
This is your tech “re-payment” analysis, and at this stage we are ready to tackle the tech debt head on.

Automated testing – respecting the contract

I’m not a big fan of throwing out code as it’s badly written.
Don’t get me wrong sometimes it does make sense to chuck a whole piece of code away.
However in most cases code can be refactored into something that’s nice, cohesive and maintainable.

Does not matter if you’re a python developer using unittest, or a Node.js developer using Mocha Chai, or whatever other framework / language you use.
What does matter is that before you start re-factoring code, you want to setup unit test / and perhaps also integration and end-2-end tests.
Maybe your code base already has that, however most “tech debt” code doesn’t.
We will discuss unit testing strategies in another post.
You can read about unit test in Node here.

Re-factor, Re-factor

At this stage, you’re ready to begin the clean-up. You need to re-factor your code. Ideally by someone very experienced.
This is not for the faint of heart, you’ll be doing lots of activities and changes, and potentially introducing issue regression.
However it’s a cost you must pay. Here are some tips to focus on:

  • DRY – Find code duplication, and merge into functions.
  • Review complex long functions, break into small ones, strive to make code read like English
  • Split complex function with switch likes params into several stand-alone functions
  • When needing complex function, make complex function private, expose simple interface functions that will call the complex one
  • If you can’t understand what a piece of code does, try to break it down into part of re-write
  • Make sure function names make sense, if not change the function names, preserve old names if needed during transition with proxy functions
  • Make sure code is now easy to understand. Imagine you’re seeing this code for the first time, does it make sense
  • Manage complexity, by breaking down into small bite-like chunks, either new classes, or functions


We hope this helps in setting up your strategy for managing technical debt. We will be doing a follow up post focused only on re-factoring.
In the meanwhile, if you need any assistance or help with managing your technical debt, feel free to reach out to us.
Thanks and until the next time!
The crew.