The first rule about technical debt - never talk about technical debt

By Nick Harley | Posted Oct 2, 2019 | 5 min. (1037 words)

Have you ever been frustrated that your warnings and opinions on technical debt are going unheard? Or you’ve felt pushed to deploy code and software updates that are either not ready, or will cause your team more headaches than other stakeholders appreciate?

You’re not alone.

Whether you are building an early-stage startup or working at a vast 20-year-old monolith, technical debt mounts as you make changes and deploy new functionality. All while the product managers, product owners, and senior leadership team push you to do more, faster, and with higher quality.

What would you do if you had enough time? Clean up that old database table? Make those performance improvements? Or rebuild the entire application from scratch? No doubt knowing what you know today you’d do things differently, but c’est la vie, we have deadlines to hit and projects to deliver.

Inevitably, there comes a point where you have to address the technical debt accumulation in your app. Maybe you noticed more people complaining about slow user experience, or a messy workflow needs addressing.

Communicating the business value of tech debt needs careful thought. It’s more of an art than a task. Allowing known issues to remain in your applications that don’t affect business outcomes or user experience, (even though you’d love some time to tackle them) is equally as important.

Even three-year-old startups need to re-tool and rebuild their entire applications as they run into scaling issues - usually caused by poor technical decisions. So the first thing to do is accept technical debt will always be a battle you’ll have to fight something to manage rather than eliminate.

Martin Fowler’s priorities matrix Martin Fowler’s Technical Debt Quadrant

Reframing conversations around technical debt

“Our Druid queries are getting slower due to the pressure on the Elasticsearch cluster, and we should probably horizontally scale that in our AWS instance because the rabbit queue for the workers tends to get backed up when we have an influx of data to those nodes…” - The CTO

You’ll never get buy-in from these types of discussions from other stakeholders unless they are technical. All leaders want to know around tech debt is why do we have it? And how do we do less of it?

At Raygun’s Tech Leader’s series, Simon Young, Chief Technology & Product Officer at TradeMe reinforced that it’s helpful to communicate technical debt through the popular analogy of financial debt. In the same way credit cards do, problems around technical decisions limit the company’s ability to execute their vision.

You can accept a small amount of debt, but leave things too long and you’ll have several credit cards maxed out with debt and causing you problems. You don’t want to be in a situation where you’re taking out another credit card to pay off your old credit card!

Project managers and leadership teams will expect you to deliver technical solutions that deliver outcomes for business objectives, so if you’re struggling to get traction on the things that keep you up at night, you might want to consider how you’re framing your ideas.

Breaking technical debt down

Josh Robb, Technical Lead at giving platform Pushpay, explains that the best way to communicate how engineering team resources are allocated between features, infrastructure, and paying down technical debt, is to break them into separate buckets.

Performance - Do you want the application to be fast?
Reliability - Do you want the application to be reliable?
Scale - Do you want the application to support more users?
Security - Do you want the application to be secure and keep data safe?

You’d have to question any leader who doesn’t want all of these things or to stop them from being a priority. So now we can start to talk about why we need to take the time to rebuild the slower parts of our application or get around to restructuring that database to support more data.

Performance, reliability, scale, and security are vital to reframing the conversation around technical debt in a language that leaders can understand. All have customer benefits, too, they build a stronger user experience and can become part of your unique selling proposition.

If you have evidence of servicing large customers, that’s going to give new enterprise prospects confidence you’ll be able to support them. Similarly, a fast site is key to a great user experience. This further helps frame the conversation in terms a business leader understands.

You can watch how Robb articulates technical debt to the wider company in the following video:

Bring facts and figures to the table whenever possible. If you can prove this change would halve a particular infrastructure cost, or result in a 50% improvement in load times across your site, that presents a much stronger argument around why this should be tackled.

DORA State of DevOps Survey 2018 on elite teams DORA State of DevOps Report 2018

Across the board, elite performers are getting the most value-add time out of their days and are spending the least amount of time doing non-value-add work of all groups, followed by high performers and medium performers. Low performers are doing the worst on all dimensions in terms of value-add vs. non-value-add time.

What does success look like?

Technical debt is an ever-present challenge in software organizations. Success is not, and never will be, having no technical debt.

Successfully managing technical debt is about your infrastructure - and the technical limitations of your product - not being a blocker to achieving your company’s goals. It’s about limitations or concerns around performance, reliability, scalability, or security being raised early, so they can be managed and resolved in due course before they become barriers to achieving the company’s goals, or jeopardize the experience your customer’s have or trust the hold in your product.

It’s never going to be perfect every time. The key to this success is bridging the gap between the code and customer so you can articulate the business value of solving tech debt.