Conversing about Technical Debt

Technical Debt will occur in any given software development project and it’s not a bad thing per se. Not all Technical Debt is caused by a deliberate decision, it can happen because we learn how the project evolves. Martin Fowler offers valuable perspectives on different distinctions of Technical Debt.

In most cases, we want to start repaying this technical debt. As technology-minded people, we are aware of the consequences of having this debt in our project. It slows us down, it hurts the agility of the product. It adds additional complexity that makes it hard to maintain and extend.

So, we start to talk with Product Owners or business managers and then we are hitting a wall. It seems like we are unable to make clear the importance and consequences of having technical debt on the future of the project. We leave frustrated, unheard and unsatisfied. Probably business will never get us, they don’t understand we have the best intentions. It’s not because we want to use the latest and greatest technology, we have the best intentions for the product and customers.

Feels familiar? I known I’ve been in this situation and I saw this happening around me in similar situations. Hence, when I was Technology Lead at Coolblue I’ve decided to do something about this.

The language problem of Technical Debt

The most important thing I’ve noticed was that Product Owners were not unwilling to repay the technical debt. In a way, they understood the problem at hand and trusted the opinion of the team. But, in the end, that is not enough.

Any Product Owner that I’ve met has to balance a multitude of opportunities and responsibilities. Stakeholders who require changes that simplify or automate operational processes. New features that generate a higher conversion or more revenue. And last but not least. there’s the development team that wants to invest time in repaying Technical Debt. Often I saw that the value of Technical Debt was poorly described. Teams were unable to display the business value of solving the technical debt. Not able to make clear what it would benefit the customer. Simplifying the architecture to develop faster might sound impactful, but when someone compares it to the new functionalities or improvements the Tech Debt often loses in terms of priority.

At Coolblue two goals are important. Making money (EBITDA) and making customers happy (NPS). In this ecosystem, a whole process was created to build and evolve a roadmap containing epics that contributed to these goals. This is where I saw an opportunity to help teams and Product Owners to have a more equal balance between the impact of a new feature and repaying Technical Debt.

Providing language constructs

I started to experiment with providing language constructs to help teams and Product Owners to resonate about Technical Debt. It is my belief that every piece of Technical Debt that you repay has an impact on your business goals in one way or another. Spending some time to simplify and improve performance? That impacts the loading time of a webpage and yields to higher conversion, especially in a high-traffic e-commerce environment. Adding some resilience patterns to an unstable process? Reduces the number of failures and as such maintains your revenue stream instead of having an outage.

At the time AWS released their updated version of the AWS Well-Architected Framework and that got me inspired. The five pillars that make up the framework offer tangible categories. They are easy to grasp and reason about and as such easy mental models for everyone. To make this fit for our e-commerce environment, we’ve created specific descriptions and examples. The pillars, however, are still the same and equal in spirit.

Using these pillars we were able to start describing what the impact was of repaying a piece of Technical Debt. Optimizing the performance of a product page by removing complexity from the data layer, has an impact on performance efficiency and cost optimization. Taking some time for a PHP language upgrade impacts security and reliability.

In our little ecosystem, we provided ‘lego-blocks’ for a set of business metrics and the impact on them. For example, 100 ms faster product page yields an X amount of Euros per month. So, combining these ‘lego-blocks’ with the provided language constructs made it easier to reason about Technical Debt and additionally, compared more fairly with other user stories.

The difference it made

As a result, I saw that Technical Debt became more visible on the roadmaps. Product Owners found it easier to explain why time was invested to repay Technical Debt over developing a new feature. Conversations became easier and Tech Debt wasn’t so scary anymore. Product Owners were able to better own their product.

Don’t get me wrong. It wasn’t that suddenly all Technical Debt was being repaid. Some things were simply deemed less important than delivering new features, but the conversation about it was better. The reasoning was better as things became easier to compare and grasp. Is it perfect? Definitely not, but it suited Coolblue well and fitted the ecosystem of product roadmaps and expectations for teams.

So, don’t blindly copy this. Think about what would work in your environment. Which language constructs can help you to reason about Technical Debt? In what way can you provide a fairer comparison between the Technical Debt and new features on the roadmap. Doing such helps to build a shared sense of reality which I discuss more in-depth in an article about socio-technical systems.