Managing Tech Debt as a Software Engineer
It happens, we build new features, fix some production bugs, and keep releasing and barely have time to breathe before the next sprint. Every software shop manages tech debt differently and there’s no right or wrong way of dealing with it; it just comes down to a few key things.
What is Tech Debt?
First off, for the uninitiated; tech debt or technical debt is where you have outdated libraries, dead or inefficient code, hardly any documentation, and in a lot of cases; missing tests. It builds up over time as the company tries to keep up with the market and new features get added to make the customers happy.
Why is this a problem?
As that tech debt grows, it takes longer to implement new features because you have to make your code work with what’s already there and a refactor can add a few hours to a few days to your estimate… you’re just trying to get shit done; quickly.
There may be new libraries that address ongoing issues in production, but if you upgrade one library; it may affect 5 more and then you find that there were probably 20 libraries or packages that needed to be updated when you just needed the one.
You may have new developers joining the team and instead of them inheriting shitty code and having them work on writing new unit tests, you could have updated documentation; something developers don’t like to do, or already have about 70–80% test coverage.
All of this takes time to refactor, upgrade, resolve, and document. Management may not care, they just want the work done. What happens when they don’t care and don’t provide you with the resources or time to work on tech debt? You may have some turnover as developers get pissed off that they have to fix a bunch of code and probably work more hours than they want to get it done and then get burnt out and leave the company anyways.
How do you address tech debt?
Like I said before, every software shop handles tech debt differently. I’ve been at large companies where there’s a code freeze and no new work is done except for approved production bugs. At that point, the team works on refactoring code, upgrading libraries, etc.
At my current company, we’ve introduced a quarterly hardening sprint to address any tech debt.
The 5 key ideas to addressing tech debt that I’ve been seeing so far are:
- Identify what needs to be worked on — we have a spreadsheet and list each thing that we need to get done
- Estimate and prioritize each line item — you can use hours, days, Fibonacci sequence, whatever.
- Advise management on the list of tech debt and how you plan to address those items
- Work on the manageable items during the sprints — this will be based on the bandwidth of the developers
- Schedule a hardening for the remaining items
What Now?
Talk with your dev team and have a conversation about how the team handles tech debt and how management views tech debt.
What does your team do with tech debt?