How-tos & Tutorials
How to track and prioritize technical debt
Published February 21st, 2023
16 min read
The worst technical debt is invisible tech debt. It hides ongoing costs and unknown risks that are lurking in your product, and it generally rears its ugly head at the most inopportune times. Every. Single. Time. So, let's explore how you can avoid it, track it and prioritize tech debt, so that you’re optimizing your development velocity.
Millie Macdonald
Product Manager at Halo Connect
If you take out a business loan, you’d want to carefully track its costs and progress. Right?
You’d also want to know the risks associated with the loan, and how those might change with time. And, you’d want to be able to weigh those costs and risks against your income, to decide how much to repay and when it’s best to make those payments.
Tech debt should be managed the exact same way.
Knowingly, Ward Cunningham used a financial metaphor when he coined the term “tech debt”. Because like the financial debt mentioned above, there’s two parts to the cost calculation of accruing technical debt: the principal cost (the work required to implement the better solution) and an ongoing interest cost (overhead caused by the presence of the tech debt).
Managing tech debt is vital for all software products, but especially so in a complex piece of software like a rich text editor, because incorrectly managing it can lead to all kinds of issues (we’ll cover some of them later). With this type of complexity, it’s definitely a case of knowing the risks and quantifying your existing issues, before you commit to any more debt.
So let’s look more closely at why you should track tech debt, and how you need to correctly prioritize tech debt repayments within your rich text editor.
Reasons to track tech debt
When you take on tech debt, you’re making a conscious choice to implement something the quick way in order to release faster, rather than taking the time to implement a better solution.
But tech debt isn’t just a monetary problem.
It has tangible side-effects on your product and code base. It can decrease development velocity and block vital roadmap features. And, in a rich text editor, tech debt in one area, can cause widespread and potentially catastrophic side-effects across the whole product.
You need to know:
- What to monitor
- How to monitor it, and
- How to assess modification news for its impact on your rich text editor.
Doing all that requires dedication, domain knowledge, and a significant time investment.
But equally, if you don’t track tech debt, you’ll likely have no idea of the costs and risks that lie hidden in your codebase. Here’s just three reasons why you need to track tech debt in your rich text editor:
1. Decreased development velocity
For developers, tech debt can cause cruft and code rot that must be worked around – which decreases the proportion of time those same devs can spend directly improving the product. It might not sound like much if your developers lose 10 minutes every day due to a workaround. But across a year, that could cumulatively be 40 hours+ of development time, lost to tech debt.
The side effects of tech debt can be hard to quantify, but their costs add up.
If you’re not tracking your tech debt, this decrease in development velocity might, at first glance, be hard to understand, and to quantify. However, if you know where your tech debt is, and begin to notice velocity decreases in related work, it may well be the root cause.
Knowing the principal cost of your tech debt also allows you to prioritize tech debt repayments, versus continuing to accumulate the ongoing (interest) costs.
But tech debt doesn’t just affect developers. Customers and managers are also impacted by the limitations it introduces – lowering customer satisfaction and stifling company initiatives.
For example, tech debt might mean your user flow is a bit clunky and annoying for users every time they use your product. Or a new feature that a product manager wants to schedule and launch, isn’t possible, due to its interactions with existing tech debt.
To avoid your roadmap being brought to a halt, you need to actively track tech debt.
2. Risk to future projects
Sometimes, a new feature is incompatible with existing code – whether that be it’s entirely blocking implementation, or making its cost prohibitively high. Tech debt makes this more likely.
Tech debt has a tangible effect on your product and code base – and what can be added to it.
By tracking where your tech debt lives, it means you have a chance to spot such issues during the planning phase, not development. It also allows you to prioritize tech debt repayments and incorporate the debt work as part of the project – reducing the risk of surprise roadblocks or schedule delays during development.
Rich text editor example of prioritizing tech debt
As an example, TinyMCE’s Enhanced Image Editing plugin carried a lot of technical debt, until it became so bad that updates were impossible without a major rework.
Debt accrual:
Over time (due to repeatedly tight deadlines), the Enhanced Image Editing’s unique UI elements, like its crop frame, were hacked into the TinyMCE Core, instead of being implemented properly. Over time, other changes complicated these hacks until any further major changes to the plugin were impossible without significant refactoring.
Debt repayments:
Luckily, this was known tech debt. When roadmap discussions turned to improving the Enhanced Image Editing plugin, Tiny was able to prioritize and schedule repaying the tech debt ahead of other big projects. Otherwise, it may have delayed or even blocked any such project – especially since it was a big project with specific release conditions.
Be careful, though – understanding the impact of tech debt isn’t always that simple.
3. Technical debt ripple effects
The complexity of rich text editors tends to lead to an extensive network of dependencies between features, plugins, and libraries. When there’s tech debt in any part, it won’t necessarily stay isolated – its side effects can spread like wildfire through your dependency tree.
The more complex your software, the greater the potential impact of a piece of tech debt.
Tech debt in core editing components can be catastrophic
Tech debt that’s lying in the lowest levels of a dependency tree, can have ramifications all the way to the top.
In a rich text editor, carrying tech debt in components like selection or the DOM model, can potentially affect every feature that deals with content editing – which is most of the product.
Tech debt can affect dependent WYSIWYG features
Rich text editors often have interdependent features. TinyMCE has several plugins that rely on other plugins, and many more dependencies between various tools and libraries.
These relationships mean tech debt can spread across the tree too – and needs to be accounted for in planning and development.
Tech debt in external dependencies can be unfixable
Rich text editors rely heavily on browser APIs and operating system (OS) functionality – and getting browsers and OS vendors to fix tech debt can take a while.
Even with open source libraries and frameworks, the responsiveness of the maintainers can vary – which is one of the risks of using open source software (OSS) that isn’t actively and expertly maintained.
All these problems can be avoided, or at least managed, as long as you track tech debt in your product. So now let’s look at how to do that.
How to track tech debt
No matter whether you intentionally choose to take on a piece of tech debt, or your team stumbles on old tech debt accidentally: Don’t let it become invisible.
Write it down (or notate it in some way) so that next time development velocity dips, or a project is delayed, or you’re considering a new feature, you have a list you can check for potentially-related tech debt.
The exact notes you make may depend on your prioritization framework (more on that in a moment). However, a few examples are:
- What is the scope of the tech debt?
What areas of the product does it touch?
What side-effects will it have?
When might it cause problems in the future?
A dependency tree can be great for figuring this out, especially in a rich text editor.
- What is the principal cost of repaying the tech debt?
If your team were to fix it then and there, how long would it take them?
Do they think that estimate might increase or decrease over time?
- Are there any caveats to repaying it?
Does it require domain knowledge that only certain people have?
Does it require input from other teams?
Are there deadlines for repaying it?
- What is the ongoing interest cost of leaving it?
Who does it affect?
How often will that interest be incurred?
What will that cost you?
Once you have that information, you need to compile it somewhere.
The best place for tech debt is alongside other work – in your task backlog, your roadmap, or next to other planning documents.
You need to be able to prioritize it in the same way you prioritize other work, and that means:
- Record it in the same format.
- Use the same prioritization framework.
Otherwise, the differences might complicate the process, and that could lead to it not being prioritized at all. Of course, a big part of how you manage tech debt is the tools you use to track it.
Tools to track tech debt
The first question to ask when looking at tools is always: can any of your existing tools do the job? After all, introducing new tools costs money and requires extra time to set it up and learn.
If an existing tool won’t work, try to find one that fits into the existing workflows of the people who need to use it – this makes it easier for them to adopt the tool. For example, developers might prefer something that integrates with their IDE, while non-technical people may prefer a web portal.
Finding the right tool for your team is key. Otherwise, people often forget to add or check tech debt. So let’s look at some options.
What is an IDE?
IDE stands for Integrated Development Environment.
IDEs are programs for writing, debugging, and deploying code and many other things. Visual Studio and Jetbrains IntelliJ are two well known IDEs.
1. Project management and issue tracking tools for tech debt
Issue trackers like Jira, Azure Boards and GitHub Issues can be good for tracking tech debt (Jira even has a few articles on it). Alternatively, tools like ProductBoard can help you track tech debt at a higher level.
If you’re already using one of these tools, that’s great! Adding tech debt will make it easier to see the bigger picture, to do comparative analysis, and to prioritize tech debt against and with other work. Or… if you want something specifically designed to track tech debt, try Stepsize, which also integrates with various IDEs and issue tracking tools.
Alternatively, if your use case has specific needs, you may need something a bit more custom.
2. Manual tech debt tracking methods
If you Google “how to track tech debt”, you'll find plenty of advice about maintaining a tech debt document or register. Find what works for you and use it, regularly.
Manually tracking tech debt gives you maximum flexibility.
You aren’t limited in what you can record, and you can structure the tech debt record in whatever way that works for you. And it might be more friendly for non-technical users – especially compared to the more developer-focused tools listed above. Just make sure it’s easy to access and update, so there’s no excuse to forget to maintain the register.
Of course, it would be nice if you could just automate that work…
read MORE
Want more info on manual methods of tracking tech debt?
3. Automated code analysis tools for tech debt
Unfortunately, you can’t totally automate tech debt tracking. However, code analysis tools can often detect outdated code and dependencies, potential security vulnerabilities, and bad programming practices – which is a good start.
Make sure to research what the tool can and can’t do though, and how well it aligns with your use case. These tools can be indispensable when used correctly, but can be more trouble than they're worth if there’s misalignment.
The OWASP Foundation has a great guide to code analysis tools – including a selection criteria for choosing a tool. If you want a shorter list, try searching for “code analysis tool” plus the language(s) that your product is written in.
However, code analysis tools can only find some forms of tech debt. Even if you do use one, you’ll still need another tool to track the other types of tech debt, so you can prioritize it all.
How to prioritize tech debt
Once you have your list of tech debt, you can finally prioritize repayments. But how do you choose what to repay, and when do you repay it?
1. Prioritizing what tech debt to repay
Similar to what tools to use, the first question is: can your current prioritization framework be used for tech debt too?
Frameworks like the RICE Scoring Model and Cost of Delay can be applied to tech debt in the same way they can be applied to features.
Another option is an Impact/Effort Matrix.
| Low Effort | High Efoort | |
|---|---|---|
| High Impact | Quick Wins | Major Projects |
| Low Impact | Time Fill-Ins | Money Pit |
However, beware simple frameworks and their inability to capture the full picture.
Although the “Reach” in RICE usually refers to the number of people impacted, with tech debt you may want to consider the reach of a piece of tech debt within the code base. Within a rich text editor, this is where a deep understanding of the architecture and dependencies helps you prioritize.
For example, in a rich text editor, selection bugs tend to be high effort, but their side-effects can impact a significant portion of the editor. Because of this, you may want to consider the reach (portion of product affected) and impact (how bad are the side effects) in order to properly calculate what the ongoing costs of the tech debt are.
In addition, you need to remember that as priorities change, so can impact – especially if a piece of tech debt affects an upcoming roadmap item. And, changes to a code base over time, can change the principal effort too – like the Enhanced Image Editing plugin (see section 2. Risk to future projects) which became increasingly more complicated with each additional hack.
That’s why it’s important to regularly review and re-evaluate your tech debt, especially in light of changes made and the changes coming, in order to properly manage tech debt in your product.
2. Choosing when to repay tech debt
There are three main strategies for fitting tech debt into your development cycle.
Tech debt repayment options
| Prioritize by the roadmap | Pay down each sprint | Regular tech debt sprints | |
|---|---|---|---|
| How | For each project on the roadmap, assess whether any tech debt will affect it, and schedule as part of the project. | Assign a quota of points or tickets for tech debt in each sprint. | Include a tech debt sprint in your development cycle. e.g. every fourth sprint. |
| Pros | Know exactly how much is invested into paying down tech debt. Good for preventing roadblocks and ensuring tech debt is addressed. | Ensures continuous improvement so small tech debt doesn’t pile up. Good for small pieces of tech debt. | A bigger slot allows for bigger pieces of tech debt to be tackled. Good for a post-release cooldown and hardening. |
| Cons | Tech debt not aligned with a roadmap project might be forgotten. Process overhead for small pieces of tech debt might be excessive. | Larger pieces of tech debt might not fit into quota. Often the first thing to be removed when deadlines get close. Needs to be protected. | Cooldown/IP/HIP sprints often include other activities too – not 100% tech debt time. Easy to let deadlines slip into the tech debt sprint, and eat up the time. Needs to be protected. |
The inbuilt challenge with each of these strategies, is that they’re suited to different types of tech debt.
Big, roadmap blocking tech debt might need to be scheduled around other projects, but your team could probably knock over several quick wins if they had a day or two per sprint. Conversely, if you rely on a sprint quota to address tech debt, large pieces may never get addressed.
Realistically, you probably need to apply more than one strategy in order to properly manage tech debt.
The key thing is to have a plan to ensure tech debt can’t go forgotten or slip through the cracks. If you don’t, tech debt will either pile up until it’s unmanageable, or your developers might take matters into their own hands to address tech debt that they feel needs to be fixed.
In both instances, whether that means developers are working overtime or sneaking tech debt into sprints to address its impacts, it affects your developer velocity – and your morale.
What if tech debt gets unmanageable?
Ideally, you’d want to pay down your tech debt over time, in nice little manageable chunks and never have any issues. But that’s not always how it works.
Sometimes rewrites/refactorings are necessary
Sometimes, a piece of tech debt can become so big and so costly, you just have to bite the bullet and do whatever it takes to fix it.
You have to sit down with your team, and figure out what it takes to pay down the principal and get rid of the debt once and for all. It may end up being a big project – the longer it's been there and the bigger the codebase, the more likely it will snowball.
However, when leaving it causes constant drain on developer efficiency, or repeated unsatisfied customers, or even the complete obstruction of new features, the long-term returns are worth the effort.
Sometimes you can make it someone else’s problem
Alternatively, sometimes you can hand the problem off to someone else.
The software ecosystem is constantly evolving, with new libraries and tools released every day. Just because you had to write custom code for something when it was first implemented, doesn’t always mean you have to keep maintaining that code.
Remember to shop around to see if there’s anything you could use instead. It might still require some work to switch over and set up, but long term it means less code to maintain, less tech debt to track, and less problems overall.
And, if you’re looking for a rich text editor, well there’s a really great one…
Download the white paper
Opportunity Cost of Technical Debt: Minimize Your Rich Text Editor Development
author
Millie Macdonald
Product Manager at Halo Connect
Millie is a Product Manager at Halo Connect who dabbles in writing. Previously, she worked at Tiny as a Product Owner, dev, and QA engineer. She loves learning above all else, whether it's about people, tech, or leadership.
Related Articles
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.