Technical Debt: Interview With Adam Tornhill and Alex Omeyer

Last week we hosted a webinar where Alex Omeyer interviewed Adam Tornhill about technical debt: what is it, why it's important, and how to manage it effectively. For this article, we've chosen some of the most interesting questions we've got from the audience. If you're curious to learn more — check out the full version of the webinar.

Alex: I'm Alex, the Co‑founder, and CEO of Stepsize. I spend all of my time talking about technical debt with Engineering team members, and I'm genuinely pumped to have Adam, CTO and Founder of CodeScene, with me today.

Adam has written books, such as 'Your Code As a Crime Scene' and 'Software Design X-Rays: Fix Technical Debt with Behavioral Code Analysis', that I would classify as classics on the topic of technical debt. We've been following your work for a very long time — and now we've got the chance to ask you questions.

Tell us a bit about your journey — how you became interested in technical debt and went so deep into it?

Adam: This journey has started back in my previous life when I used to be a software consultant. As a part of that role, I was often hired as a tech lead or a software architect, and one of my responsibilities was to make sure we could deliver as quickly as possible with the best quality. I often found this incredibly hard because I had to communicate to my business managers and product owners that now is the time to take a step back and pay down technical debt.

These were hard conversations to have, and I was trying different approaches, for example, looking at different complexity metrics and analysis tools. But it was hard to translate my technical view into something meaningful for my managers.

While I was struggling with this I was also in the middle of my psychology studies where I learned forensic psychology. I had an idea that if I could track the movements of developers in the code base, I could actually use that to figure out which parts of this code are impacting the most people.

That's where I started 10 years ago, and I've spent the past decade working on those ideas.

Alex: Before we go too deep into everything you learned over these 10 years, can you tell us why you think technical debt is such an important topic today?

Adam: It might be a cliche to say but every company is becoming a software company today. I didn't understand what it meant until a few years ago when I worked with a customer who was in the scrap metal business. They were relying on a ton of sophisticated software for their logistics. At that moment, I really understood how software is having an impact on every single business.

The consequence of that is a talent supply: there's a limited amount of developers in the world, and even if we have the budget, we just cannot hire all the people that we would like to hire.

It means that we have to work with the people we already have to get more work done — and the technical debt is a critical part of that.

Alex: How do you define technical debt?

Adam: There are so many definitions and flavours of technical debt: strategic, deliberate, reckless… But over the years I came to the conclusion that it's not that important to know where this debt is coming from — what matters is its impact.

My definition is: technical debt is any code that is more expensive than it should be, code that we have to pay interest on.

Alex: I love that. My working definition is any code that you've decided is a liability, precisely for the reason you've mentioned.

Previously you mentioned that you have to negotiate a lot with your stakeholders. How can engineers help non‑technical stakeholders understand technical debt and the importance of continuously dealing with it?

Adam: We have a communication challenge between engineers doing the technical work and our stakeholders, we use different vocabulary and we focus on different things.

When I go to my non-technical manager to say, hey, look, we need to refactor this thing because it has a cyclomatic complexity of 500 — it doesn't mean anything to them, they couldn't care less.

What we, developers, can try is to use more business-oriented metrics such as time lost or customer impact. We can say, look, we shipped 30% faster last month, and we had fewer bugs — things that every software company cares about.

Alex: Absolutely. Now let's talk about prioritising technical debt. Is all tech debt equally important and if not, how do you prioritise the right debt?

Adam: To me, not all technical debt is equally important. When prioritising technical debt there are 3 things I look for:

1. Impact: how much does this particular debt impact our ability to deliver?
2. Business priorities: as a CTO I pay a lot of attention to our product roadmap and want to make sure we can deliver on that. If I look at my roadmap, I immediately know which areas we're going to touch.
3. Trends: are we getting better or worse in real-time? Trends tend to be actionable.

Alex: Let's talk about code quality. There are many tools that help with different aspects of technical debt. How does CodeScene differ from code quality tools? And what is the perfect stack to manage tech debt properly?

Adam: Sure. I can make an attempt. I'm obviously going to be a little bit biased, but I'm going to do my best :)

I've always been a big fan of static analysis tools, and I'm still using them. I think they are useful as low-level feedback loops during development, they can help catch particular mistakes but those tools were never intended to manage and prioritise technical debt.

This is the reason why I started to develop this field of behavioural code analysis that helps us prioritise tech debt.

A space that's growing in interest right now is the people side of code. For larger organisations, 100+ people, the organisational side becomes even more important than code quality issues. For example:

• Do we have the right people on a team?
• Are there any parts of the code that we no longer understand?
• How well aligned are our current teams?

All of those things are the information that you can actually get from CodeScene.

And then, you have Stepsize that helps with more qualitative analysis and adds context.

You will need each of these tools at some point to successfully manage technical debt.

Alex: I agree obviously, there's so much information you can get from git data that you cannot get from typical static analysis tools.

Another common question we often get is, who is responsible for technical debt?

Adam: The simple answer for it is all stakeholders are responsible for the technical debt, but for different aspects of it.

I see some companies that treat technical debt as a technical problem. I simply don't think it's going to be particularly successful. As developers, we might know how to pay down technical debt and we might even know where it is but we very rarely own our time. It's usually someone else who tells us what to focus on. That's why I think it's important that the business side derives technical debt and sets priorities.

Managers and Product people should help find the balance between shipping new features and making sure that development is sustainable over time.

Alex: I like to apply the process I describe in the article The perfect process to manage tech debt. The Engineers are responsible for applying the boy/girl-scout rule: leave the code better than you found it. That's every engineer's responsibility. Then when we're talking about medium pieces of debt, typically you have a Team Lead who can go to a Product Manager and have a conversation about the debt that should be included in this sprint.

Then it's the Product Manager's responsibility to decide how to allocate Engineering resources between maintenance and the features they have in the sprint.

For the large pieces of debt, what I see usually, depending on the size of the company, is that they have Staff or Principal Engineers, who create technical proposals for bigger projects. Plus, they have Engineering and Product Leadership responsible for making these big decisions.

This process has helped many companies deal with technical problems much more efficiently, and we hope it and this conversation will help many more teams too.

If you have more questions or comments, drop me or Adam a line on LinkedIn, and we'll be happy to continue this conversation.