Don't let Technical Debt sabotage your product roadmap - Part 1

Introduction

Picture this: Your development team is humming along, shipping features at a breakneck pace. But beneath the surface, a looming threat is growing – technical debt, an invisible force that can derail your product roadmap and sabotage your business model.

Technical debt, in simple terms, is the cost of taking shortcuts in software development, growing until the time comes to pay back your technical debt.

Imagine you're building a house. You could save time and money by cutting corners on the foundation. But eventually, those shortcuts will catch up with you. The house might start to creak and groan, the roof might leak, and the walls might start to crumble. The same thing happens with software. As technical debt accumulates, your development speed slows down, defects start to pile up, and your product roadmap becomes increasingly unpredictable.

What is the difference in the stories about your software and your house? While you can see the results of your shortcuts at your house, shortcuts in your software are invisible most of the time. Keeping technical debt invisible can be a costly mistake.

With technical debt, I do not mean the urge that we as engineers have to migrate to the latest cutting-edge frameworks or programming languages. With technical debt, I mean the loss of opportunities for growing your business.

In this blog series, I'll cover how to build a compelling business case for refactoring to convince your management that investing in code quality is not just a technical concern but a strategic business imperative. Let us start by looking at the different perspectives on technical debt and the potential impact of AI Coding Assistants.

The two perspectives on Technical Debt

There are a lot of anecdotes, research, and studies out there. In this chapter, I will share insights from two great papers by CodeScene [1] [2], mixed with my personal experiences and thoughts, as well as data from a Stripe study on developer efficiency [3]. Stripe shared some impressive numbers that developer inefficiency leads to a staggering $300 billion annual loss in global GDP. 🤯

Let me be clear on this: Technical debt is a business problem. However the lack of visibility about the impact of technical debt on your business results in short-term return on investment by implementing new features often being traded for long-term business growth opportunities by reducing technical debt. Only 10% of business managers actively manage technical debt. In my opinion, there are two approaches we can think of for tackling technical debt. The reactive approach is to create a business case for your refactorings. The proactive approach is to leverage the support of AI to deal with your refactoring. Both have a certain degree of uncertainty in common.

In any case, our first important milestone as technical leaders is creating awareness about the impact of technical debt.

A look inside your development teams

Technical debt makes it increasingly difficult to add new features or modify existing ones. Codescene revealed that development in low-quality code is a staggering 124% slower than in high-quality code. Imagine the frustration of your team when a feature that should take a week to implement ends up taking over two! This slowdown isn't just an inconvenience; it's a major drain on productivity and can significantly fill up your product backlog.

Defects due to low code quality and high technical debt translate into unplanned work – those dreaded bug fixes, hotfixes, and patches that eat away at your team's time and resources. The “Future of Work” report published by software.com found out, that developers are just spending 60 minutes per weekday coding. The Stripe study found that developers spend an average of 17 hours per week dealing with maintenance issues and another 4 hours dealing with "bad code". According to Stripe, unplanned work represents a massive opportunity cost, estimated at $85 billion annually in lost developer productivity alone.

Unplanned work in this context means that your team's effort is spent firefighting instead of building new features or improving your product. This will sabotage your product roadmap by making it nearly impossible to craft your upcoming releases. This unpredictability is a nightmare for planning and can severely damage your credibility with stakeholders.

But why can’t we tackle the issue of technical debt by hiring new developers? That in fact can make the situation even worse as it increases coordination costs and can make software development less efficient. Especially in businesses that invested a lot in their technical debt.

The Ripple Effect

Technical debt extends far beyond the confines of your codebase, impacting your team's morale, your customers, and your business. I call this the ripple effect of technical debt. Not only since the publication of "Accelerate: Building and Scaling High Performing Technology Organizations," we understand that there is a science behind software engineering and DevOps. There is not only empirical but also scientific evidence of the impact of organizational performance on software delivery.

Depending on your product, your users have various expectations of the software described by all the functional and non-functional requirements, ultimately manifested in architectural characteristics. When technical debt rears its ugly head in the form of glitches, crashes, and performance issues, it impacts how users experience your products. This can lead to negative reviews, customer churn, and ultimately, lost revenue.

Picture this: if you need to convince your management about the impact of increasing bugs, behind every bug, there is an unhappy customer potentially turning away from your product, a negative review or app store rating at their fingertips. Goodbye to all new customers waiting for your features to be shipped. Goodbye business value and competitive advantages. When you consistently fail to deliver on promises, it erodes trust and can jeopardize your product roadmap.

Technical debt can harm innovation and hinder your ability to capitalize on new opportunities. This can put you at a competitive disadvantage and prevent you from staying ahead of the curve.

Let's finally not forget the human cost of technical debt. Working with messy, convoluted code can be incredibly frustrating for developers. Developers feel their productivity is hindered by factors like legacy systems, unclear prioritization, and insufficient time to fix bad code.

When talented engineers leave your team due to technical debt-induced frustration, you lose valuable knowledge and experience, further exacerbating the problem. According to Stripe, executives consider the lack of developer talent a bigger threat to their business than access to capital. That alone should be enough to argue that technical debt is not just a technical issue but a critical business risk. But often, this is not the case.

The Impact of AI Coding Assistants on Technical Debt

Can AI not only help us write new code, but can it also help us improve code, or make code quality better? While tools like Amazon Q Developer or GitHub Copilot promise to boost productivity and streamline coding tasks, their impact on technical debt is a complex and evolving issue.

AI coding assistants have the potential to help engineers pay back technical debt. By automating repetitive tasks, suggesting improvements, and even generating entire code snippets, these tools could free up developers to focus on higher-level design and problem-solving. However, the reality is more nuanced.

I tried to understand better at which stage we are right now. And I found an interesting whitepaper from GitClear named "Coding on Copilot". They evaluated that in 30% of cases, an AI Assistant failed to improve code health. And in two-thirds of the cases, it broke existing tests. AI coding assistants tend to hallucinate and write even more code than engineers by hand. Codebases that are partially written with AI, grow faster than our codebases used to grow previously.

And we all know: that more code does not mean better code. More code introduces a higher risk of increasing technical debt. Coming back to my definition of technical debt as a shortcut in software development. To be fair enough, AI Coding Assistants are not the root cause. It is because we learned over the years the benefits of simply copy-pasting code from StackOverflow or AI-Coding Assistants as a shortcut in software development. You might have an idea how this ends unless you use those tools responsibly.

As we move forward, it's crucial to explore how AI can best support refactoring efforts. This includes developing AI models that can better understand code structure and domain context, as well as integrating AI assistants into existing development workflows in a way that promotes code quality and maintainability.

There is an interesting podcast published by ThoughtWorks called "Refactoring with AI". Martin Fowler asked an interesting question:

Is there any work at trying to do this kind of stuff with these kinds of models that operate on the level of the abstract syntax tree, rather than the code text itself?

Adam Tornhill, CTO and Founder of CodeScene explained that they tried such approaches using machine learning models that use the abstract syntax tree instead of treating coding as text. I understand the potential of mitigating hallucinations as this approach erases the difference between programming languages and offers coding assistants a new way of dealing with code.

Another trend that I see is that behind every coding assistant, there is not only one model that executes all tasks. While diving deeper into Amazon Q Developer, I learned that there are multiple models evaluated when you send your prompt. Based on the evaluation, Amazon Q Developer picks the one that is best for executing your task.

Ultimately, the successful use of AI coding assistants in managing technical debt will depend on the expertise and judgment of human developers. These tools can be powerful allies, but they should not be seen as a replacement for sound software engineering practices.

Conclusion

I hope this part helps you to find enough arguments and anecdotes to emphasize that technical debt is a business problem.

Research shows that developers spend 23-42% of their time wasting due to technical debt. Why is this still tolerated in many cases? The lack of visibility and missing connection to business value are two reasons that I observed in my years working in this industry. Discussions around tackling technical debt are often reduced to statements like "We have to refactor this" without an argumentation based on data.

Technical leaders need to understand that they have the power to make code quality a business concern. As every modern business is a data business, tackling technical debt is, in similar ways, a data-driven decision like every other business decision.

In the next part, we will explore how to create a compelling business case for your refactoring so that your management can make an informed decision on how to trade long-term business growth back from short-term ROI.