When to take on technical debt

This is part two in our ongoing series on technical debt. Check out part one, The Cost of Technical Debt here

We’re not anti-debt around here. There are times when it makes a lot of sense! As Stephanie Ockerman and Simon Reindl put it in Mastering Professional Scrum, “Technical Debt is not necessarily a bad thing — as long as there is a real plan to pay it off.” It’s a lot like taking out a mortgage to buy a house. It can be a really smart idea. Taking out a second or third mortgage on the same property? Maybe not so much. 

Let’s talk about choosing to take on technical debt, and when to pay it off.

Solid reasons to take on technical debt

1. You need to fix an actual emergency

When your house is on fire you have to douse it in water. Sure, there’s going to be water damage, but that’s not a problem compared to the actual problem: the fire. 

If there’s an issue with your software that needs to be fixed and now, we absolutely recommend doing it, no matter what it takes. Then, you can think long term. 

We have two caveats here: First, building secure and well-tested software from the outset can circumvent a lot of issues. Second, make sure you’re accurately assessing the level of emergency. If it’s an actual emergency, then do what you need to do. If you’re calling a non-emergency an emergency as an excuse to move quickly and sloppily, then be honest about the tradeoffs you’re making and if they’re actually necessary. Like all debt, real emergency or not, you do eventually have to pay the balance of your technical debt and its interest. 

2. You want to build a quick prototype to get feedback

A quick prototype is inherently technical debt: it’s something you’re building that you’re going to have to rebuild, or at least heavily refine. We love using fast prototypes or MVPs for getting information quickly. We’ve found that we get enough information to make the technical spend worthwhile. As long as you know going in that this approach means you will have to build twice or heavily refactor the code — either requires time and money. 

Worth it? Usually. A fun thing to be surprised about? Never.  

3. You want to build fast so you’re first to market

If you’re in a super competitive field and you’re trying to get to market first to gain the competitive advantage then you may need to build more quickly, take on some technical debt, and pay it down later. 

Is this true for most companies? No. But it might be true for yours. 

If you go this route, make a plan for when you’ll pay it off. What triggers will tell you it’s time? What hard trade-offs will you be willing to make later? Can you get everyone to agree to those tradeoffs now? 

4. You will generate more value than you’ll incur in debt

Trying to launch the online shop before the holiday season? Want to have the new website ready for Giving Tuesday? Well, it might make sense for you to take on some technical debt that you’ll pay off later — this could be categorized as “prudent and deliberate” debt. 

If the pay-off is big enough, we’ll often recommend a two-step self-approval process: green light taking on the debt and green light the plan for paying it off at the same time. Even if you’re planning to deal with it later, make a plan for how you’ll deal with it now, when everyone’s on board with the build.   

Signals you need should pay off some technical debt

1. You can make the time and bandwidth 

There’s almost never a time that’s perfect for paying down debt, since there’s always something new to be built. That’s why it’s best practice to keep your technical debt manageable and to actively make time for it. 

We recommend assessing your technical debt load regularly and proactively working on it. You might want to pay it now, simply because you can. 

2. You’ve learned more

No one loves to go back and revisit something that’s still working. But sometimes — let’s be honest, most times — if you’ve learned more you should go back and apply those learnings. It’s like if you figure out a way to build a smoother road halfway through paving it. If the difference is large enough, you may want to resurface the first part of the road, too. Then again, maybe a half-smooth road is just fine for now. 

We can help you figure out when and if you’ve learned enough to refactor or rebuild. It’s a nuanced decision that’ll be unique to your project, team, and the lifespan of your software. 

3. You’ve added new features 

In software, there’s no once and done build. If you’re adding new features, especially when you are working on deadlines driven by the business, you’ll also need to be continually refactoring. That is, you’ll need to circle back and make sure all the existing code is compatible and supports everything you’re building on top of it. 

In the short term, you can get away with it; but not for long! If you build too many new features without doing the right maintenance, it’ll become a toxic asset. 

4. You have a toxic asset 

There comes a time when you don’t have much of a choice: you have to pay off the debt. Either you’re paying for the man hours of every dev to make sense of the issue, or you fix it outright. We like how Dave Rupert puts it, “At that point your technical debt balloon has popped, you are in possession of a toxic asset, and it’s time to pay the piper.” This might mean refactoring, or pausing new development until the existing issues are fixed, or, sadly, abandoning the old software and starting from scratch. 

If we take the West Seattle Bridge as an example, they had two options when figuring out how to fix its structural issues. Option one: repair it. They could figure out a way to repair the cracking bridge to make it safe enough to open it again — a cheaper, but short-term solution. (In software terms, that’s the equivalent of refactoring.) Option two: rebuild it. They could knock the bridge down and build a new one, which might be the best long term solution, albeit an expensive and time-consuming one. 

If you’re at this point with your software, we’ll help you figure out the most painless way through as possible — the economics can be simple to quantify.

Our POV: All technical debt needs a repayment plan 

Technical debt isn’t a bad thing. It’s technical debt without a repayment plan that’s dicey. Just like consumer debt, if you’re not paying it down, you’re actually building more. Unpaid debt eventually grows so large the project’s technical debt balloon pops — and you don’t have a working piece of software; you have a toxic asset.