How We Approach and Manage Technical Debt

Technical debt in software is something that increases the cost of changing existing software. Accumulating technical debt makes it progressively more challenging for engineering teams to innovate and deliver value which will slow down growth. It also makes everyday work more frustrating and stressful. Technical debt exists at most moderately complex software solution companies – including Artera. The critical factor is not avoiding it, since all software companies will inevitably accrue it, it is in how companies manage it over time. In this post I’ll write about how technical debt can be kept under control to ensure sustainable growth.

Types of technical debt

Technical debt can be introduced to software in many different ways. Sometimes it’s a conscious and justified decision of the team to take shortcuts to ship something fast and get early feedback. This is especially common at early-stage startups trying to find their right product and their first customers. Sometimes it gets introduced when the team is inexperienced or lacks familiarity with the domain. It is not uncommon to realize, during the final stages of development, that a product or functionality could have been designed more effectively. However, due to practical constraints, the decision is often made to ship the product as is, rather than starting over.

I really like Martin Fowler’s categorization of technical debt to a quadrant of deliberate / inadvertent and reckless / prudent dimensions in this article.

Credit: Martin Fowler

Using this categorization can also provide valuable insights on how to prevent the introduction of further technical debt. Do the team members require additional time? Do they need more experience or training? Are we consciously taking on debt with the intention of paying it off in the future?

There’s also another type of debt that is not introduced by changes, rather the opposite. It’s called software rot and is caused by changing environments or expectations that the software was not designed for. Some examples of this are newly introduced security vulnerabilities of libraries or increased usage or accumulation of data that the infrastructure is not prepared for.

Is technical debt bad?

Not necessarily. Similar to financial debt, there are situations where it’s beneficial to take on technical debt to gain an advantage in the present that we plan to pay back in the future. Another similarity is that the engineering team must also bear interest on the accrued technical debt. It’ll take more effort to make changes in the software, higher chance of introducing bugs that will again take more time to fix and put a strain on users as well as engineers in the team. A startup might prioritize time to market at the cost of increasing technical debt as a conscious trade-off.

Credit: Carsten Windler

Recognizing the significance of technical debt is crucial. While it may be necessary to incur debt when justified, it’s equally essential to allocate time and effort to repay it promptly. By doing so, we can safeguard the engineering team’s ability to deliver value without being weighed down by accumulating burdens.

Early stage startups often focus on finding the right product and getting feedback from quickly from potential customers. How much technical debt is accumulated during this discovery is often unimportant. However as an organization scales, technical debt can become more of a burden slowing down delivery. At Artera, we have gone through these different, naturally occurring stages, including accruing technical debt and putting significant effort into reducing it in order to support our ability to scale.

Measuring technical debt

Most engineering teams have a good gut feeling of how much pain technical debt causes them during their everyday work. Still, it’s important to try to quantify it for multiple reasons. Firstly, it can give an indication of trends, tell if the team is going in the right direction and can be a good way to set objectives. Also it can help to influence stakeholders to allocate more time to pay back technical debt.

Code quality is one aspect of technical debt that can be measured by static code analysis tools like Sonarqube, also source code platforms like GitHub have increasingly more tools to analyze code.

Technical debt causes bugs and incidents that take time to resolve and this time is also easily measurable. How much time a team spends on new features versus fixing bugs is a good indicator, as well as how many bugs are introduced by changes (change failure rate).

Lastly, it’s a good practice to maintain a backlog of technical debt that the team should address in the future. At Artera, each product development team has a tech debt backlog. Like a standard product backlog, this is a prioritized list of work with high level estimations and clear acceptance criteria. Also, as discussed above tech debt is often introduced as a conscious decision or realized when the team is finishing a feature. Having a backlog allows the team to immediately add the new debt popping up. Furthermore, it gives the team awareness of what needs to be addressed and also an estimation of effort needed to pay back the accumulated debt.

Addressing technical debt

In my experience the most difficult part of addressing technical debt is getting it prioritized and having people allocated to actively work on it. Organizations often focus on direct customer needs when rolling out new features and products. Consequently, it can be challenging to justify engineers working on making improvements to existing software that does not have an immediate and tangible value. At Artera, reducing technical debt is an objective of the entire organization – we keep 20% of capacity of teams aside for tech debt during our planning process -, but if you’re working at a place where this is not in focus, I have 3 ways to help you get it prioritized:

1. Justify priority by using metrics and calculating return on investment
2. Factor in addressing technical debt when planning future development
3. Take ownership and accountability to make controlling technical debt easier

Justify priority by using metrics and calculating return on investment

You can use the metrics – like the ones we discussed above – to quantify the cost of having technical debt and how much it slows down the team. On top of that, having the backlog of estimated work to address that debt can give you numbers on the return of investment.

Estimation in software is difficult and you might not get all the numbers right, but having some numbers can make a difference in some organizations.

Reducing technical debt offers additional, albeit less quantifiable, advantages. Fewer bugs not only free up the team for feature development or further tech debt reduction but also alleviate the stress on the team, fostering a more focused and productive environment.

Factor in addressing technical debt when planning future development

Having a tech debt backlog has a different benefit as well. When you need to change some existing functionality you can look at the backlog and see if there’s an opportunity to reduce technical debt around the code that you’ll be touching. If that’s the case, it’s usually easier to factor in the debt reduction with the functional changes. My guiding principle is that a team should consistently strive to enhance the code’s quality with each modification, unless faced with an urgent emergency.

Credit: Daniel Stori

Another aspect of this is knowing the roadmap of a team for the next 3-6 months can help prioritizing tech debt as well. If you know that you’ll be working in a funky area of the code a lot in the future, it’s easier to reason why addressing debt beforehand can be beneficial. On the other hand, if you have debt in parts of the code you rarely touch then it might not be as big of an issue so it can have lower priority.

Taking ownership and accountability make controlling technical debt easier

At Artera, we believe in empowered teams, which means that teams are not only given problems to solve but also they are trusted to decide the best way to solve them. Additionally, teams focusing on an area of the product or a problem continuously instead of being moved around for smaller projects helps teams to create a sense of ownership and accountability for that piece of software. This will lead to teams feeling the pain caused by technical debt more and will also give teams the authority to decide on addressing that technical debt for their long term benefit.

As an example, if there’s a common software library with lots of debt that is shared across teams then no team will really treat it with priority to improve that library, even if it causes a lot of frustration to most of them. Once a team takes responsibility for it they will have a much stronger incentive to reduce technical debt as well as the ability to plan out the changes that need to be made.

Keeping technical debt in check

There are practices teams and an organization can adopt to ensure technical debt does not get out of hand. We’ve discussed various types of debt and how they are introduced, let’s see what we can do to prevent these happening:

1. Introduce feedback loops to catch the introduction of technical debt
2. Leverage automated tools to ensure quality does not degrade

Introducing feedback loops to catch the introduction of technical debt

Doing mandatory code reviews on all changes is probably the simplest process to implement to prevent technical debt introduction. In addition, code reviews also improve with knowledge sharing and collaboration within the team.

Credit: Geek & Poke

For larger changes we have a Request for Discussion (RFD) process at Artera. Essentially this is sharing a design document with the engineering organization and asking for reviews, comments and approvals (see this blog post by Pragmatic Engineer for more details and benefits of this process). This makes it much more difficult to introduce tech debt as you need to justify your decisions to take shortcuts and get buy-in from multiple people outside of your team.

Leverage automated tools to ensure quality does not degrade

Introducing automated steps that uphold quality into the CI/CD process can also help with keeping technical debt in check. Having coding standards and enforcing them on every change helps to keep the codebase clean and catch some problems at the lowest level of code. There are also static code analysis tools that can not only measure code quality or detect security vulnerabilities but they can also be used to enforce that these do not degrade when introducing changes.

Investing in automated testing can also help to combat technical debt in multiple ways. First, we defined technical debt as the additional cost and risk to make changes in existing software. Automated tests actually help with reducing risk of changes by catching issues early so they can lessen the impact of technical debt. Also having a reliable set of automated tests helps a lot when code needs to be refactored as they inherently describe the expected behavior of existing functionality. So they can make addressing technical debt more efficient.

Tech debt bankruptcy

If a startup ignores tech debt for an extended period of time it can turn into a significant obstacle to future progress. Teams may find themselves spending over 80 percent of their time resolving problems or inefficiencies caused by tech debt. This is commonly referred to as “tech debt bankruptcy”

Some signs of this can be:

• Regular production outages to the point of material business impact
• Constant pushback or extended timelines on new feature development due to the need to deal with tech debt
• Complaints from engineers that the codebase is too complex
• High change failure rate even when introducing new features

If a company finds itself in a state of tech debt bankruptcy it needs to sound the alarm, reset expectations with stakeholders and come up with a plan to consolidate and pay off technical debt to remain sustainable.

Conclusion

Technical debt is something every software engineering team has to deal with. I believe what differentiates great teams and organizations is not necessarily the amount of tech debt but how consciously they manage it. Being aware of your tech debt situation and setting goals to reduce or at least manage tech debt aligned with your product strategy is key in running a sustainable engineering team and organization.

---

The contents of this post as well as the opinions expressed herein do not contain business advice. The business information provided is for general informational and educational purposes only and is not a substitute for professional advice. Accordingly, before taking any actions based upon such information, we encourage you to consult with the appropriate professionals. THE USE OR RELIANCE OF ANY INFORMATION CONTAINED IN THIS POST IS SOLELY AT YOUR OWN RISK.