DEV Community

Cover image for Prevent Technical Debt with These 3 Strategies💪
Alex Omeyer
Alex Omeyer

Posted on

Prevent Technical Debt with These 3 Strategies💪

The expression technical debt gets thrown around a lot and every Engineer knows that it slows down the development process. In this article, I want to give practical advice that your engineering team can manage and solve technical debt without spending a lifetime on it.

Let’s define technical debt…

Often technical debt refers to a rushed development process or a lack of shared knowledge among team members. However, don’t forget that in many cases technical debt is inevitable and is part of a normal software development process.

For instance, Engineers might not implement the correct design patterns in your infrastructure because you want to save time to ship new features. Other examples include not writing documentation to share knowledge or having a lower code test coverage.

In short, the quality of the code suffers in various ways, such as not sharing knowledge or rushing certain aspects of the development lifecycle. Here’s a quick overview of the most impactful types of technical debt you want to avoid:

1. Knowledge-based tech debt🙇

To understand knowledge-based tech debt, let’s look at an example. Imagine two software engineers have worked on a new feature. They own all knowledge about this specific feature. However, other software engineers in your team don’t have this knowledge. When they have to work on this feature or have to do an implementation that makes use of this feature, they won’t have the knowledge required to correctly implement a new feature.

Therefore, it’s essential that you actively share knowledge about features and important codebase changes. It includes creating documentation, examples, tests, and sharing knowledge during retrospective meetings.

Knowledge sharing is one of the easiest methods to solve technical debt.

2. Design debt🧑‍🎨

Design debt often occurs in highly competitive markets or startups where speed to market often is the highest priority.
When delivering new features quickly, you’re not thinking about the structure of features or the architecture of your codebase. It often gets neglected, making it increasingly harder to add new features. And now you have to fix it as a team.

Therefore, design debt is closely linked to structuring features and adhering to design patterns.

3. Code debt💻

Code debt is about writing bad code and not fixing this in time. For instance, a developer wants to quickly merge code without writing sufficient tests or adhering to code standards.

Many organisations use automation tools such as pre-commit hooks with code linting to verify code quality. When you don’t implement such code checks, bad code can quickly decline the overall quality of your codebase.

3 best ways to fight and prevent technical debt

Technical debt grows every day and the best time to implement a process for solving it is now. Here are a few proven methods.

1. Code and architecture refactoring

One of the most straightforward solutions to prevent and/or resolve code and design debt is organising a refactoring week every X sprints. A refactoring week allows your team to resolve open bugs, evaluate the current architecture, and prepare the architecture for the upcoming product features.
For instance, set some time aside to think about how new features might affect the architecture of your codebase.

Image description

Benefit: A refactoring week gives the needed breathing room for developers to evaluate and reflect on the code before implementing a new set of features. It’s great for solving for big pieces of debt.

Drawback: The development process slows down while you are doing refactoring and your team is not solving debt continuously.

2. Start regular technical debt discussions

Retrospective meetings are the gold standard for engineers to share knowledge. It’s even possible to involve more stakeholders in these meetings, like product owners, to create a shared understanding of the codebase and problems engineers face.

A retrospective meeting addresses what went well and what didn’t. It’s an open stage to share feedback without placing blame. It would be best if you focused on improvement.

Benefit: You can use retrospective meetings to share updates about the code. Engineers can show what they have accomplished. Mostly, a couple of engineers get the chance to present their codebase changes and explain how it affects the codebase or how they have achieved this. Therefore, a retrospective meeting is a great tool to share knowledge after each coding sprint.

Drawback: Stakeholders and managers need to be onboard with the vision and give engineers time to organise these meetings.

3. Start tracking technical debt in your editor

The best thing you can do for your codebase health is to make it as easy as possible for engineers to solve technical problems. Tracking technical debt in the editor allows engineers to:

  • Get full visibility on technical debt
  • See context for each codebase issue
  • Reduce context switching
  • Solve technical debt continuously

You can use various tools to track your technical debt but the quickest and easiest way to get started is to use free Stepsize extensions for VSCode or JetBrains that integrate with Jira, Linear, Asana and other project management tools.

Benefit: Developers already spend most of their time in the editor so it’s the best place to track and report technical issues. Implementing a process for managing technical debt will positively influence engineering team morale and customer satisfaction.

Drawback: Starting a new habit takes time and effort from team members and it’s impossible to do without a tech debt hero.

How to detect a growing technical debt?

You want to manage and track different types of technical debt actively. It’s important not to let your tech debt grow. Large technical debt will slow you down significantly and becomes harder to solve. In other words, large tech debt is costly and hurts your speed to market.

It’s essential to track metrics related to different types of tech debt. Here’s a list of metrics you can track:
Overall code coverage percentage and code coverage per feature: A declining percentage is a red flag for a growing tech debt

Number of failed CI or CD builds: If the number of failed CI/CD builds increases, it’s a strong indicator for instability in your codebase. This can be related to both design and code debt.

Number of new bugs per week or month: If your team finds more and more bugs on a weekly or monthly basis, it indicates a quality decline of your codebase. Therefore it’s a great metric to detect a growing tech debt.

Feature throughput: How many days does it take to push a new feature to the main branch. It’s a supporting metric that can indicate growing tech debt. Not each feature has the same size, but if you see a decline over multiple weeks, it’s time to intervene.

Issues with non-functional requirements: Did you think about measuring non-functional requirements when defining metrics to detect tech debt? Measuring metrics such as application performance, UX (increasingly difficult to use), or loss of compatibility are solid indicators for increased technical debt. If you want to get started with this metric, try out performance monitoring for critical paths within your application.

How do companies at different stages deal with tech debt differently?

Startups often endure a lot of pressure to ship their product quickly. They can easily solve technical debt by implementing automated tools that verify code quality. Besides that, actively sharing knowledge among their often smaller team is one of the most powerful strategies to avoid tech debt.
However, it’s not that easy for large enterprises to keep technical debt under control. According to the State of Technical Debt 2021 Report, 66% of engineers believe the team would ship up to 100% faster if they had a process to manage technical debt. Another 15% believe they would even be 200% more productive.

Unfortunately, large enterprises need a better solution than organising knowledge-sharing meetings like retrospective meetings. Yet, it’s part of the solution.

To keep technical debt under control, large enterprises need to use project management tools to understand which features are in development and who’s working on specific areas of the codebase. Project management tools are great to avoid conflicts.

Besides that, they should use automated code quality tools to ensure overall codebase health. Code quality tools can often be integrated within a Continuous Integration pipeline.

Conclusion

Leaving technical debt unaddressed can result in several issues for your organisation, such as higher total cost of ownership, slower time to market, reduced agility because of a poorly designed architecture, and poor security.

Therefore, make sure to measure a few metrics related to technical debt. You can quickly get started by measuring the number of new bugs and how many get resolved and use Stepsize VSCode or JetBrains extensions to track and see this data.

In conclusion, make sure to have a process that makes it easy to share knowledge with team members and resolve technical debt continuously.

Discussion (12)

Collapse
therealgrinny profile image
Connor

I’m working on improving our code authoring life cycle in a department that isn’t really proficient in it - I’m in IT, not a dev team. But there’s enough stuff thats been written, in terms of scripts and in house tools we create, that our current tech debt is thousands of lines deep.

These are good tips. 10/10 would refactor again

Collapse
noriller profile image
Bruno Noriller

I believe there's a fork for the first one, where it's not that it's bad code or rushed... it's just that at the time the programmers didn't know how to do better (or maybe there were no other way of doing something).
For example... a lot of lodash methods that are now native, momentjs that people already changed to others or to some native methods, but that soon with temporal api will be stale.
People grow and learn more, but let the code as is because it's not broken, it's not "bad code" per se... it's just, how it was done back then, by either lack of knowledge or tools.
They might not be bad alone, but as the project grows... it's like a "lubricant" that needs to be changed with mileage to make things continue to run smoother.

Collapse
mrwensveen profile image
Matthijs Wensveen

Insightful! This sidesteps actively tracking tech debt because you can't know in advance what parts will need refactoring. Upgrading dependencies as often as possible helps a little because some parts will be marked obsolete/deprecated, but this is not always the case.

As for normal tech debt tracking: I use XXX: comments in the code when I write something that should be reconsidered later.

Collapse
alexomeyer profile image
Alex Omeyer Author

Nice method, thanks for sharing, Matthijs! I'd be curious to hear your feedback on Stepsize if you give it a try :P It's basically your method but more advanced haha

Collapse
alexomeyer profile image
Alex Omeyer Author

Totally agree with this, Bruno! Tech debt is not necessarily bad or rushed code, my working definition is basically any code that you've decided is a liability

Collapse
filipparyz profile image
Filip Paryż

Great article! I'm a young dev, but I feel responsible for preventing further tech debt. I've worked in few companies so far and have already experienced various levels of tech debt and could see how much it affects not only my work but the whole team and their morale. Focusing on the end product and forgetting about the process is the main reason for tech debt growth and creating distance between developer and product as a whole. I will use your article to educate others and remind myself how to be a better dev :)

Collapse
alexomeyer profile image
Alex Omeyer Author

This is amazing to hear from a young dev✊

Collapse
marcomoscatelli profile image
Marco Moscatelli

This informations are gold thank you for the article!

Collapse
alexomeyer profile image
Alex Omeyer Author

Thank you, glad to hear it's helpful 🙌

Collapse
emmanuilsb profile image
Emmanuil B.

Fantastic article. I actively try to keep tech debt to a minimum when I'm working; the tips provided here will help me so much.

Collapse
svgatorapp profile image
SVGator

Excellent advice!

Collapse
alexomeyer profile image
Alex Omeyer Author

Happy to hear you found it useful 🙌