The 3 Best Tactics to Prevent Technical Debt

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.

If you’re looking for a sustainable solution for tech debt management in your engineering team, you need Stepsize. It’s the world’s first and only bespoke tech debt management tool. Track and manage issues directly from the IDE, and create issues directly linked to code. For engineers, this means no more context-switching and high-quality issues that can be prioritised based on impact and fixed. And because it integrates with Jira, your PM will love it too.

‍Learn how to get started with Stepsize here. It works with Visual Studio, VS Code, JetBrains.

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.

Wrapping up

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 by using Stepsize. Track and manage actionable issues that are linked to code, directly from the IDE.