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.
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, JetBrains and Visual Studio 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.
Top comments (13)
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
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.
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.
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
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
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 :)
This is amazing to hear from a young dev✊
This informations are gold thank you for the article!
Thank you, glad to hear it's helpful 🙌
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.
Excellent advice!
Happy to hear you found it useful 🙌
Thank you so much for the information! I am a beginner IT specialist
, and I received a job offer a few days ago. I will be on probation for the first time, so I won't earn too much. But I hope my income will increase with time, and I can start my own company. I want some advice from experienced professionals. To test my skill, my boss gave me an assignment. I have to make a website for a mortgage broker like this: Mortgage Broker Woking. I am confident in myself and my abilities, and I think the colors for a mortgage broker website should be another. Am I right?