The Two Paths of Technical Debt – Plan Now or Pay Later

Most development teams operate in an agile environment, often working within sprints to manage tasks and keep project deadlines on track. In some cases, shortcuts are made to meet business expectations and deliver features on time. This is completely normal, but there’s a catch.

A by-product of these shortcuts can be what we refer to as technical debt (or tech debt). It's a common phrase used in the software development industry and can be applied to many multi-platform solutions.

Technical debt is either planned or unplanned.

In this article, we’re going to talk about how you can approach technical debt with best practices in mind when feature planning. Let’s dive in.

The two sides to technical debt

Technical debt is like borrowing time and effort that will be needed in the future to bring a solution up to current standards. It's the gap between where you are now and where you want to be. You might end up with technical debt for a few reasons, such as using outdated technology, poor design, or not documenting things well.

There are two types of technical debt: planned and unplanned. When you plan for it, you're making a deliberate decision to take shortcuts and cut corners to solve a short-term problem quickly. It can help you work around limitations or constraints without blocking other teams or making things worse. Assisting you deliver value sooner saves time and money. But if you don't plan for it, issues can arise, taking more time and money to fix.

In saying that, sometimes changes outside of your control can happen, and technical debt will follow no matter what you do. In those cases, lower amounts of debt are more manageable than a lot. That's why it's essential to invest time in planning for the future, even if it's just educated guesses.

A primary example of unavoidable technical debt is when dependent software or systems are updated. What is the impact of these updates? A common practice for progressive development is to 'deprecate' features or functions to enable future innovation. When this happens, it is necessary to assess how it will affect your solution, and plan for the effort required to migrate away from the deprecated dependency, to reduce your risk of an undesirable outcome.

Other root causes of unplanned technical debt

Poor communication and lack of collaboration between teams can certainly contribute to the accumulation of unplanned technical debt. However, several other root causes can lead to this problem, including:

• ‍Unrealistic deadlines: When development teams are given unrealistic deadlines, they may be forced to cut corners or take shortcuts in order to meet them. This can lead to the accumulation of technical debt over time.
  ‍‍
• Poor code quality: If code quality is not prioritised during the development process, it can result in code that is difficult to maintain or modify in the future. This can lead to the accumulation of technical debt as developers are forced to spend more time and effort making changes to the codebase.
  ‍‍
• Lack of automated testing: Without sufficient automated testing in place, it can be difficult to catch and fix issues before they make it into production. This can result in the accumulation of technical debt as developers are forced to fix bugs and issues that were not caught during the testing phase.
  ‍‍
• Inadequate documentation: If code is poorly documented or not documented at all, it can make it difficult for developers to understand how the code works and make changes to it. This can lead to the accumulation of technical debt as developers are forced to spend more time deciphering and understanding the codebase.
  ‍‍
• Lack of code reviews: Without sufficient code reviews, it can be difficult to catch issues and potential technical debt early on in the development process. This can result in the accumulation of technical debt as issues are not caught until later stages of development or even in production.

The cost of technical debt

There are many ways in which technical debt costs organisations money:

• ‍Increased costs: Technical debt can cause costs to rise due to the additional effort required to maintain and update the code. In the long run, this can become a significant drain on resources.
  ‍‍
• Reduced quality: Technical debt can lead to reduced code quality, which can result in more bugs and defects. This can also make it more difficult to maintain and update the code, as well as add new features.
  ‍‍
• Slowed development: If technical debt is not addressed, it can slow down the development process, making it harder to meet deadlines and deliver new features.
  ‍‍
• Reduced innovation: Technical debt can stifle innovation, as developers may be spending more time fixing and maintaining code rather than developing new and innovative features.
  ‍‍
• Poor user experience: If technical debt is not managed, it can lead to a poor user experience, with slower performance, more bugs and glitches, and other issues.

However, there are a couple of issues that are more important than others: engineering time, morale, and the missed revenue from software delays.

On average, developers spend 41.1 hours at work each week, 13.4 hours of which they spend on technical debt. Maintenance of legacy systems and technical debt is the number one cause for productivity loss.

Engineers spend 33% of their time dealing with technical debt. The Developer Coefficient (Stripe)

Stripe estimates technical debt alone has a $3 trillion impact on global GDP. But it’s hard to predict the future. How are you supposed to know what could go wrong? Or what you should be planning for that may incur technical debt?

We’ll explain what this looks like next.

The process of managing technical debt

To explain the process of managing technical debt, most of our clients are faced with two common scenarios.

Scenario A: Wait and get the feature 100% ready and delay the feature release.

Scenario B: Deliver this feature in 6 weeks (specified timeframe) but go into it with eyes wide open that we will have technical debt to pay back.

Here are the pros and cons to consider with scenario A and scenario B.

Scenario A: Waiting to get the feature 100% ready and delay the release.

Pros:

• The feature will be thoroughly tested and more likely to be free of bugs or errors when it's released
• By taking the time to fully develop the feature, the team can ensure that it meets all of the requirements and will provide the maximum value to users
• By postponing the release, the team can avoid incurring technical debt that would need to be paid back later

Cons:

• The delay in the release can result in missed opportunities or lost revenue
• The team may lose motivation or momentum while waiting to release the feature
• The feature may become outdated or less relevant by the time it is released
• The delay could block other teams from delivering work

Scenario B: Delivering the feature in a specified timeframe with the knowledge that there will be technical debt to pay back later.

Pros:

• The feature will be delivered to users in a timely manner, which can help to keep the project on schedule and on budget
• By releasing the feature sooner, the team can gather feedback from users and make adjustments as needed
• The team can prioritize the most important features and deliver them to users as soon as possible
• Work can proceed more freely between dependant teams

Cons:

• Incurring technical debt can make it more difficult and expensive to make changes to the feature in the future
• The feature may be buggy or have other issues that need to be addressed later
• The team may not have the time or resources to fully pay back the technical debt, which can lead to accumulated debt over time.

It is important to note that which scenario is best for you, will depend on the specific project context, priorities, available resources and other factors.

For Scenario A, if the priority is to ensure a high-quality feature that meets all requirements, and the resources are available to take the time to develop and test it thoroughly, then delaying the release to eliminate technical debt might be the best choice.

For Scenario B, if the priority is to get feedback from users as soon as possible to make necessary adjustments, and the resources are limited, then releasing the feature in a specified timeframe while incurring technical debt may be the best option.

Let’s take this theory and see how it played out for a client of The Lumery.

A real-world example of managing technical debt

The Lumery was faced with a challenging situation when a brand engaged us to provide insights and consultation for a use case across multiple channels.

Their one condition was that there was to be no new tech or changes to existing tech integrations. This meant that any solution provided would not be scalable and could potentially introduce technical debt.

Despite these limitations, we were able to provide solution options for activating the use case as quickly as possible while also considering steps to improve it in the future. The client ultimately decided to move forward with a solution that was less than ideal but met their immediate needs.

Now, The Lumery is working with the client on a new engagement to conduct an audit and identify gaps in the current system. We are enhancing the client's CDP and integrated platforms to provide more robust solutions in the future, while also addressing any technical debt that may have been introduced.

By taking a proactive approach and working closely with the client, The Lumery could help make the most of their current tech stack while also planning for long-term success. This type of collaboration and forward-thinking is crucial when it comes to managing technical debt and ensuring that organisations can adapt and thrive in the face of changing circumstances.

When planning for the future state and trying to eliminate tech debt, at what point do you stop?

It’s a great question.

The problem with technical debt is when it accumulates, it can become all-consuming if you don’t stay on top of it.

The best-case scenario overall could be to eliminate technical debit incrementally, where you build technical debt fixes into your BAU sprints.

This does two things for your business:

You can keep the debt on your radar the entire time and break it down into manageable chunks.

You can still add business value and continue delivering features in production at the same time.

This process requires having your development team hold each other accountable and take ownership throughout this process. If technical debt is identified, it gets added to your project backlog and prioritised accordingly.

Final takeaways

Technical debt is something that all organisations face. It's important to understand the difference between planned and unplanned technical debt, as well as pinpointing the different causes of technical debt.

By taking steps to reduce technical debt incrementally, you can avoid letting it become all-consuming. And, by investing more effort in discovery and planning up front, you can often reduce unforeseen technical debt down the road.