Different Ways to Handle Technical Debt Part 1: the BAU approach
- Lucille Tut
- Oct 2
- 3 min read
What We Call Tech Debt (And Why It Doesn't Matter)
You hear a lot of terms thrown around: code debt, legacy burden, suboptimal code, technical lag. The list goes on. This tells you one thing: "technical debt" is a massive umbrella covering all sorts of issues.
But whatever the name, here's the truth: Tech debt isn't bad; it's inevitable.
The minute you build a system, technology and requirements start changing. What works perfectly today will be obsolete tomorrow. In addition to this, the rise of 'vibe coding' by inexperienced developers using AI is creating a mountain of tech debt, often wiping out the productivity gains those organizations thought they were getting. Accepting this reality is the first step toward managing it effectively.
This is the first of three posts where we’ll break down tech debt and share practical, non-disruptive ways to handle it.
The 10 Types of Tech Debt
Tech debt is more than just messy code. A comprehensive Google paper** breaks it down into 10 core categories (which shows just how broad the scope is):
Migration is needed or in progress
Documentation on project and APIs
Testing
Code quality
Dead and/or abandoned code
Code degradation
Team lacks necessary expertise
Dependencies
Migration was poorly executed or abandoned
Release process
Most teams are battling issues across most, if not all, of these categories. Some are quick fixes; others need a structured plan. For this first post, let's look at how we handled it as part of our everyday work.
Dealing With Tech Debt as Business as Usual (BAU)
We found that some tech debt doesn't need a massive, separate project. It’s a natural by-product of development and we treated it that way - as a regular, daily activity.
Issues pop up everywhere: stand-ups, Slack, retros or via end-user feedback. We simply built a system to handle them on the fly:
Broken tests? Our team policy was to fix them immediately to keep testing and releases flowing.
Obsolete code found during a ticket? Fix it then, or log a ticket to clean it up soon.
Production-stopping bugs? Drop everything and fix them - this is the highest priority debt.
Non-urgent clean-up (like removing old feature flags)? These went into the backlog to be tackled at regular intervals.
The key to making this work was a constant cycle of communication, logging and smart prioritisation.
We didn't just fix debt when we had nothing else to do. We found a balance. I always used a ratio of improvement tickets to business tickets to ensure we were always building new things and keeping the foundation strong.
You can't stand still. By accepting tech debt as normal and building it into your BAU, you keep your system healthy without disrupting business delivery.
Let's Face Your Tech Debt Together
Is your backlog filled with items that look exactly like these 10 categories? Are you constantly playing catch-up just to deliver new features?
Stop ignoring the inevitable. Get in touch. We'd love to chat with you to discuss the top three categories of debt your team is facing and how to turn those problems into planned, productive wins.
P.S. Stay tuned for our next two posts, where we'll cover how to handle tech debt as a long-term, structured work stream and the "big bang" approach for major clean-ups.
** C. Jaspan and C. Green, "Defining, Measuring, and Managing Technical Debt" in IEEE Software, vol. 40, no. 3, pp. 15-19, May-June 2023, doi: 10.1109/MS.2023.3242137.
Comments