There’s a disease festering in your code — and it could reach a terminal state
It’s called technical debt
What would happen if you take a loan from a loan-shark, but when payday comes, you just take another loan?
The price will eventually become unbearable.
What will happen if you never clean your home and just add more furniture and items to it?
The price of negligence becomes heavier as time progresses.
It’s the same with your code.
If you keep adding features and never take care of your technical debt — eventually you’ll end with a huge pile of messy, unmanageable code. Every feature will have a high price — both anticipated and not anticipated (AKA bugs). According to recent studies, companies pay on average 20%-40% of their development time dealing with issues that are related to tech debt.
Is this treatable? Yes.
Is it difficult to treat? Yes.
Tech debt is a problem that is not always visible or understandable for the R&D managers.
The sales team is selling, the product needs more features, and now is not the time for maintenance.
But in truth, this needs to be managed and understood, now.
And luckily, there’s an iterative process that can help you identify, manage and ultimately solve the problem in an ongoing manner. Let’s do it step by step:
Identify The Problem
We, as the R&D, can’t fight an invisible enemy. We need to map out our tech debt.
The developers are usually aware of the pain points when developing new features.
They know that adding code to a certain part will be shaky, they know that their CI/CD is slow (or nonexistent). Maybe they’re missing parts of the process like PRs or some tool to help them abide standards like a lint tool.
The developers know.
So the first step would be discussing the tech debt with them.
Triage your tech debt: What’s missing? What’s wrong? What needs refactoring? Where do we miss infrastructure? What code duplications are common?
Don’t disregard or dismiss things casually. Trust the process to keep the important things solved first.
Create Tickets
For each item you identified, create a ticket in your ticket system.
Some tickets will be more like an (in agile terms) “epic” and some more like a “story” or a “task”.
Rough scoping is important for identifying quick wins later on.
Try to be detailed enough when creating the tickets, so that you’re ready for the next step.
Put a Price Tag On It
Ballpark estimates for each ticket will help you understand if a certain tech debt ticket will take a lot of time, or if it’s a quick win that you can get value from.
The price is the effort invested in the ticket in story points, hours or days — whichever measure you use for product features.
We are creating a system here, in which technical items hold their place and values among other tickets.
Prioritize
Now we order the tickets by priority.
It’s important to note — the priority here is the priority of the developers, not the product.
Why? Because they know what makes it hard for them — and it’s their time.
High value — low cost tickets are the most valuable ones, and should get the highest priority. Sometimes a small change could speed up everything in the process, for example:
Common patterns that are written in the code with small to medium variations could be written once and reused.
Developer experience is affected by the process and its tools — add a linter, create code snippets, use generators, write unit tests, e2e tests (end to end), create a system of mocks, etc.
Discuss the priority in the most objective manner possible.
Allocate Time
The most dire problem with tech debt in the industry, is that its time is not protected enough.
This is the most crucial part of owning and solving the problem — if you don’t allocate time specifically for your tech debt, you just won’t get to do it.
The standard is 20%. This could be a day a week (per developer), 2 days of a 10 day sprint, a week out of 5 weeks, etc.
Fixing product bugs is not tech debt. A common mistake is to allocate time for bugs and tech debt. It usually results in fixing bugs only, not leaving time for the tech debt. Don’t mix the two.
Communicate the allocated time to all stakeholders. Everyone should know that during this time the developers are occupied closing tech debt tickets.
If managers don’t allocate the time, the whole process will collapse.
Start Closing Tickets
Now we have the problem visible, its solutions written, priced and prioritized.
We can now act and start closing our tech debt.
Allocate developers to the prioritized ticket — Mind their cost.
Let the developers estimate it better — this could change the priority.
In this phase sometimes the product and development negotiate on the urgency of a certain ticket, because this part needs a feature soon and the tech debt might “freeze” it for too long.
Negotiating this is ok, as long as the ticket, which has priority, returns right after — and we don’t create a pattern of postponing tickets indefinitely. This needs to be managed closely.
Rinse and Repeat
Taking care of the tech debt never ends. It’s an ongoing process, just like developing product features. This means you open a ticket every time you see a need for a cleanup, maintenance, infrastructure, etc. Every week/sprint — you prioritize your tech debt backlog again. Then you allocate time for it and close those tickets.
This way you keep your tech debt in check, your application healthy and your velocity optimal.
A Few Final Words
Some people will read this and tell themselves — “this is too much work”.
But from my 15 years of experience, which include being a tech lead for most of the time and also several years of being a team leader of teams varying in size (2–12),
I can testify that I have seen it happen almost always: negligence of the tech debt will always return to bite the company eventually — and “eventually” comes faster than you think.
You’re already paying the price, so it’s better to take the initiative rather than being reactive and putting out ever incrementing “fires”.
There’s no escaping this — quick and dirty is a losing game.
Choose to win.
