Part of a developer's duties is to manage a project's technical debt. Technical debt, also known as tech debt, refers to the amount of technical work remaining on a project.

Quantifying tech debt

Technical debt is hard to quantify. Developers working on a codebase are able to identify the technical debt. They must figure out how to communicate this technical debt to management. Management will likely ask for an estimate of how long it will take to eliminate the technical debt.

A codebase is never really technical debt-free. Every technical decision that's made comes with some sort of tech debt that gets created. Deadlines don't always coincide with the amount of time that is needed to complete a task. Thus, technical compromises must be made made along the way, leaving traces of tech debt.

Short-term and Long-term solutions

There is a short-term solution and a long-term solution to every problem or feature request. There is a tradeoff that is made for every short-term solution. Short-term solutions have a limited lifespan. Developers must keep in mind that they will have to re-visit the short-term solution and modify it into a more long-term solution.

Some may consider short-term solutions to be the result of laziness or sloppy coding. While short-term solutions are what cause tech debt to accumulate, they are also what allow products and features to be released by their deadlines.

Tech debt and product roadmaps

Tech debt does not show up on product roadmaps. Product roadmaps show stakeholders a timeline of the delivery of new user-related features. Managers don't exactly want their stakeholders to know about tech debt. Also, most managers don't like the idea of spending time on tech debt because, in their mind, it does not result in any new features for the end user. Good managers know the importance of addressing tech debt and will buy the developers time for it.

Accumulation of tech debt

The lack of planning for tech debt causes developers to try to address it as they are working on features. It's difficult to juggle between features and tech debt without delaying the feature. The typical result is that tech debt is put on the back burner while the feature is developed.

Tech debt can accumulate to the point where the codebase becomes unmaintainable. Just like financial debt, tech debt must be dealt with before it gets out of hand.

Code hygiene

Every codebase needs good code hygiene. If we don't go to the dentist for five years and then finally decide to go, we will probably be in for an unpleasant surprise. Tech debt is like tartar. Left unaddressed, it builds up like plaque and creates problems. Keeping on top of tech debt is like going to the dentist regularly. It means regularly going into the codebase to address issues with the time that is available.

Good code hygiene can consist of:

1. Removing unused code

If a developer suspects that a block of code is not being used, they should verify this assumption and then delete it if their assumption is correct. Adding it as a to-do item for later will only create more tech debt. If you have the time to do it now, do it now. We should always aim for having the least amount of code possible within a codebase. Less code means there is less to go wrong with the application. It also means faster build times and faster deployments.

2. Refactoring/restructuring code

When is the best time to refactor code? As soon as you notice it needs refactoring! Bad code has a way of spreading throughout a codebase without notice. When new developers join the team, they will end up copying the bad code and the practices that come with that bad code. You will then have more tech debt than you had initially. If a new feature will be built off of existing code, be sure to account for the time needed for refactoring when you estimate that new feature.

3. Rewriting code

Re-writing something from scratch sounds painful, but sometimes it is necessary. When refactoring a code block is not working out well, it means that this code block needs to be re-written.

Good code can last for years without needing to be re-written. Bad code should be re-written as soon as possible.

Tech debt and features

Always try tying in good code hygiene practices to a new feature. This will allow tech debt to be addressed sooner rather than later and make for more robust feature deliveries. It will also provide everyone with more realistic estimates. More realistic estimates can get you the time that you need from management to spend on code hygiene.

Conclusion

Technical debt is a part of every codebase. Everyone involved with a codebase, managers included, needs to better understand tech debt and how it impacts the product. With a better understanding of it, there are greater chances tech debt will be addressed sooner rather than later.

In every release, take the time to apply good code hygiene practices so that tech debt does not get out of hand.

If you're working in an Agile environment, create tasks and/or stories that address tech debt. Come to an agreement with your team on how many tech debt tasks or stories should be taken during each sprint.