How To Successfully Recognise and Manage the three Different Types of Tech Debt | by Ashley Peacock | Nov, 2021
Keep your groups’ productiveness excessive — and your codebase wholesome — by having a tech debt fee course of
Not all tech debt was created equally. Some tech debt may hamper your capability to quickly iterate in your codebase, leading to fewer options being launched and fewer enterprise worth being unlocked.
On the flip facet, some tech debt could be left alone in the interim, and also you needn’t spend your valuable time addressing it simply but.
It’s price noting that this text is focussed on bigger items of tech debt, and easy tech debt (e.g., extracting a way, renaming a category, and so on.) don’t have to observe the method outlined. I’m a agency believer that such refactoring ought to occur on an virtually each day foundation.
So, what are the several types of tech debt, and the way must you handle your tech debt?
First, let’s take a look at how we are able to categorise the several types of tech debt.
Active tech debt
Active tech debt is the primary sort of acceptable tech debt, together with dormant tech debt under. It’s outlined as — you already know about it and plan to repair it within the close to future (e.g., the present quarter).
As acknowledged above, not all tech debt is one and the identical — energetic tech debt, for instance, is completely wholesome to have. One instance the place you could incur energetic tech debt is when introducing a brand new function that has a strict deadline. In order to fulfill that deadline, a less-than-ideal answer was productionised, however you propose to actively repair that tech debt as soon as the brand new function is reside.
Another instance is likely to be in a legacy system that hasn’t been up to date for some time, as there’s been no cause to change that codebase. Now there are new necessities, actively tackling the tech debt makes a whole lot of sense. You can enhance the well being of the codebase, and make the modifications simpler to make.
Dormant tech debt
Dormant tech debt is the second sort of acceptable tech debt. It’s outlined as — you already know about it, however you don’t at the moment plan to handle it.
You is likely to be questioning, “why wouldn’t you pay it off if you know about it?”, and that’s a superb query. The predominant cause for not paying it off is if you’re not encumbered by it.
For instance, an engineer would possibly come throughout part of the codebase that’s trying somewhat worse for put on. The engineer isn’t at the moment engaged on that space, nor do they should make modifications there as a part of their present piece of labor.
In my opinion, on this instance, the perfect plan of action is to notice the tech debt (we’ll go into extra particulars on this later) and transfer on. Why? Because this code might by no means want updating, it may’ve been written two years in the past and never been edited since, and should both by no means be up to date or up to date within the distant future.
In the case the place it might be up to date within the distant future, at that time you already know the tech debt exists, and may actively deal with that tech debt.
Unknown tech debt
The remaining sort of tech debt is unknown tech debt. As the title suggests, that is tech debt that you just haven’t recognized and don’t know it even exists. It’s additionally essentially the most harmful sort, as with out realizing it’s there, you may’t take into account it in future initiatives.
A extremely frequent situation I’ve seen many instances all through my profession is when a workforce estimates a venture will take a sure period of time, just for this estimate to be method off resulting from some unexpected points — similar to tech debt.
While it’s unattainable to determine each potential piece of tech debt in your codebase, having a workflow in place to make sure you routinely seize tech debt is without doubt one of the greatest methods I’ve discovered of making certain the well being of your codebase stays excessive, and your groups’ productiveness is excessive.
In the following part, we’ll take a look at a workflow you should use to handle your tech debt.
Now that we are able to determine the three forms of tech debt, how will we set about making certain we handle it successfully?
The tech debt pyramid
Similar to different pyramids in software program engineering, such because the testing pyramid, I consider one exists for the forms of tech debt.
Now that we all know the definitions for every, it’s vital to grasp how tech debt strikes from one part to a different. All tech debt at a while is unknown; as soon as it turns into identified it immediately turns into dormant.
You then have a option to make: does it stay dormant, or do you need to deal with it? Choosing to depart it dormant is a wonderfully affordable selection, relying on the context (e.g., it’s not inflicting any hurt at the moment), however in case you select to handle it, then it turns into energetic till it’s resolved.
Tracking tech debt
Tracking tech debt follows an identical lifecycle to product work. In the workforce I at the moment work with, we report our tech debt within the backlog, tagged accordingly.
Each time an engineer raises a possible tech debt, they elevate a card within the backlog, detailing the problem they’ve recognized, in addition to itemizing any potential options. The key right here is to not make the method too overbearing — an extended template to fill out could make engineers need to skip over and proceed on with their product work.
Now that we’re figuring out tech debt, how will we guarantee we don’t merely create an ever-growing checklist that by no means will get checked out?
Dedicated time for addressing tech debt
The remaining step within the course of is to make sure you have devoted time to deal with tech debt objects in your backlog. The period of time you assign to it will range relying on a whole lot of components, together with the next:
- How a lot time are you able to safe to work on tech debt?
- Are you underneath strain to ship, and have to repay much less debt for a time frame?
- Are you in a heavy discovery section, or between initiatives, and may assign extra time to repay debt?
In the workforce I work with, now we have an settlement with stakeholders (each product and tech) that 10-15% of our time every iteration is spent on tech debt. This fluctuates as per the above examples, however we usually hit this proportion on common.
At the beginning of every iteration, we prioritise the product tales we need to full this dash, in addition to prioritising the tech debt we need to deal with. This ensures that for many iterations we enhance the well being of our codebase, and since we’re prioritising our tech debt, we’re addressing tech debt that now we have recognized as a problem within the close to future, or we accrued as a part of a venture we simply accomplished.
So far we’ve observed the final well being of our codebase has remained excessive, though the primary repository we work on is now just a few years outdated. We proceed to have the ability to ship enhancements and new options at a fast tempo, and new joiners are capable of shortly and simply stand up to hurry, shortly changing into productive.
There are so many opinions and approaches to managing tech debt, so that is positively only one method that I’m positive could be improved. I’d love to listen to the way you discovered the method, or in case you take a unique method, what it’s!
Thank You For Reading This How To Tutorial!
I always provide the source link to the inspiration-content. If you find any copyright infringement content or have any question/query regarding the blog, email me directly at email@example.com. I would love address your queries at the earliest possible.