How To Avoid Tech Debt Management By Not Accruing Tech Debt in the First Place

Tech debt is like a bad hangover: you party like it’s 1999 for a night and then you pay the piper the entire next day (or the entire next week if it’s the cheap tequila we have in our conference room).

But unlike a hangover, the pain of tech debt doesn’t go away with a few Advil, a plate of short ribs and reruns of Sex & The City (did I just say that?).

So WTF is tech debt and how can you avoid it?

First let’s talk about what tech debt is not.

• Tech debt is not the bugs you didn’t fix. Those are just bugs you didn’t fix (oh snap!).
• Tech debt is not the glaring security issue that opens up your system to bad actors. That is just a critical security problem you need to fix asap (aka a fire-able offense!).
• Tech debt is not that scalability issue that crashes your servers whenever too many users log in. That’s just bad architecture (yikes!).

Now let’s figure out what tech debt actually is

In the broadest sense, tech debt comprises all the engineering activities and tasks that you now understand in retrospect should have been done but either you didn’t realize it at the time or you chose to prioritize something else.

Maybe there was a business need to value development velocity above all else and the team chose to sacrifice debt for speed.  Or perhaps the engineering team didn’t have any experienced leaders who could point out the shortcuts that end up costing more in the long run.

Yet regardless of how a company accumulates tech debt — knowingly or unknowingly — it’s still tech debt and you will eventually have to allocate engineering time to pay it down.  (The grim reaper comes for us all in the end…)

So how can you avoid tech debt – or at least manage it strategically? 

Answer: create a “Definition of Done” and ruthlessly stick with it.

Here’s what we mean.  Before releasing new code, you need to know that it meets your team’s definition of “done” and thus is ready for release.  Most Definitions of Done include lots of criteria to meet but the most common ones include:

• The functionality works as expected.
• There are no critical bugs.
• There has been a code review by another programmer on the team.
• There have been automated unit tests covering 90% of the functionality.

If some of your new code base doesn’t meet your Definition of Done, you estimate how much time it would take to get the code base to meet your definition and you label it as “tech debt.”

And here are a few additional Pro Tips:

• You need to have a Definition of Done that is agreed upon across the company. Without it, every single developer will impose their own sense of what it means to be “done.” Trust us on this one—if the whole engineering team doesn’t use the same definition, your debt will pile up faster than a gambler habitually betting on the New York Jets.
• You should measure tech debt every quarter since it works the same way as compounding interest (it grows exponentially).
• It’s okay to have tech debt since sometimes you have to innovate fast in order to fend off competition or react to market forces. But if your tech debt will take more than 6-9 months to pay down, you are getting into the danger zone and it needs to be addressed.  Nothing will make your CEO more incensed than learning that the engineering team must stop all new releases for a year in order to pave a bunch of potholes in the road already traveled.

So in short, sometimes a tech hangover is worth it but just make sure you understand all the tradeoffs first.

Want to learn more about tech debt and how to minimize it?  We are always happy to chat at info@turnkey-labs.com and 310-699-6884.