Tech Debt? What Tech Debt?...Exactly.

If you work in the software sector you’ve probably heard the term “tech debt.”

Tech debt is when code is written, and it introduces code that is either duplicated or requires more work later on. Or perhaps it’s just hacky or unfinished for some reason. 

It’s what happens when development teams try to rush the delivery of a project, only to find they need to go back and rework it. 

It’s when the need for speed exceeds the need for accuracy. 

Managing Tech Debt is like maintaining a garden: if you don't stay on top of it, you'll get weeds, or in our context, "debt", which ultimately stops the code base from working.

I’d been grappling with Tech Debt for years. Or more precisely, with finding the time to deal with it, and convincing stakeholders of the value of allocating time and resources to it. 

Clearly, a new approach was required. A pivot, if you will. 

Erasing tech debt from the lexicon

That’s when I decided to scrap tech debt entirely. 

That’s right. I said farewell (and good riddance) to Tech Debt, tickets and all, and replaced it with preparation. Okay, so what’s the difference? I’ll tell you...

It all comes down to brand perception. 

Tech Debt has negative connotations, for obvious reasons. On the other hand, the word “preparation” is overwhelmingly positive.

“A stitch in time saves nine,” as the old proverbial expression goes. 

It connotes consideration, professionalism and reliability. 

It’s worlds apart from the notion of “we broke something and now we need to go back and fix it”, which, let’s face it, is how some people see the process of maintaining a code base. 

It’s almost impossible to refuse someone time for preparation. That’s what makes this reframing of Tech Debt so effective. 

Tech Debt was a hard sell – one that many stakeholders simply didn’t understand.

But explaining that you need a few days or a week (or longer) to prepare for an upcoming project is a much easier proposition. 

Preparation is the new Tech Debt

Allocating valuable time to preparation enables us to concentrate on getting the code base right. It’s been four months since we shifted our focus towards the preventative and we haven’t looked back.

We’re experiencing more proactive investment in our design system, critical infrastructure and parts of the codebase that we’ll rely on in the subsequent feature set.

We’re also not having to reactively fix things as much because our work is more reliable and of a higher quality. Viva le preparation!

Simply put, the results have been amazing. I can safely say there’s been a huge improvement in the way our team operates.

Our component library has transformed into a valuable source of truth. 

New features are easier to build and we’ve been able to upgrade a lot of our infrastructure. We’ve also been able to invest time in spikes while managing to maintain deliverables.

If your team is struggling with Tech Debt, I’d recommend replacing it with Preparation NOW.

What are you waiting for? Good Luck!

If you found this article useful, you might enjoy A Back End and Front End love story – accelerating delivery, improving reliability and easing processes.