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.
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.
Technical debt grows every day and the best time to implement a process for solving it is now. Here are a few proven methods.
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.
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.
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:
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.
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:
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.
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.