Share this post
Dealing with Tech Debt
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 solutions – how make progress with managing tech debt?
How can we reduce our technical debt, and how do we do that without impacting the business.
Let’s dive into it.
Managing Tech-Debt – 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. services.py is 3000 lines long, should be broken down and re-writen. 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
Summary
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 CoreTeam.io crew.
