What is technical debt?

Tech debt, code debt, design debt – you can call it by different names but the point is the same. To put it simply, it’s the coding you will have to do tomorrow because today you took a shortcut in order to roll it out ASAP.

Unpaid technical debt can cost you. Just like the credit money, technical debt (if not repaid) can accumulate “interest”, making it harder to implement changes in future.  The longer it is ignored, the more software entropy can occur. Especially as your project goes through multiple phases. The amount of changes grows as well as correction costs later on.

How to explain tech debt to not-tech people

There are two main analogies clearly describing it from different angles.

“Tidying up”

It’s like cleaning by hiding everything under the couch — for now it is tidy, but nothing is in its place. Eventually you will still have to do a proper cleaning. But new mess will add up and you’ll spend more time organizing it in order to find what you are looking for.

“Car loan”

Imagine you need a car to get to and from work. You need it now, so you can’t just save up the necessary amount of money for months or years. You can simply lose the job. So, you take a car loan. It means the car will cost you extra cash over the time, but you get it now. And you get the job.

What is cruft?

Talking about tech debt we should definitely mention cruft. It’s how devs call a poorly designed, duplicating or simply useless code. Cruft is the main reason for extra development work in future, as it was implemented on the go despite being not the best studied or thought-out solution.

Is technical debt a good or a bad thing?

Despite what we’ve learned it’s not necessarily a bad thing. For developers it’s a constant balance: a perfectly crafted app, software, system versus delivering a code that is just good enough. Clean, well-designed code is a guaranty of easy updates and future iterations. However, in a real business world, squeezed deadlines and limited team recourses often get in developers’ way to a clean code and a perfect product.

1. Deliberate code debt

Every engineer knows: there’s the right way and the quick way to deal with the project. Overall, quick way can easily be the right way (for example, to avoid over-engineering). But sometimes the team can consciously, with their eyes open, take a decision to go the “wrong way”. Simply because they need to quickly deliver product to the market.

Expert on how to fix it: “Usually it makes sense to track this type of tech debt in the backlog when deliberately deferring work that needs to be completed. If it’s not tracked specifically, it’s unlikely to be repaid and will turn into accidental design debt over time. Product owners and stakeholders should be held accountable for the accrual of this kind of debt as it’s incurred by business decisions”.

2. Accidental/outdated design debt

Despite always trying to think ahead and future-proof all the code, nobody gets it right every time. Systems evolve, requirements change – and soon or a later you might realize that your design has flaws, or that new features are impossible to implement. If the original code was good, it is easier to implement refactor in a gradual step-by-step manner, but sometimes you’ll just have to deal with an urgent and significant refactor.

Expert on how to fix it: “How to significantly refactor a system well is a huge topic in itself, but it’s completely natural that this needs to happen every now and then (every other year or so when the system is in a “steady” state). Otherwise, you might over-engineer the system in the first place and incur unnecessary slow-downs all along. Team/tech leads and product owners should be accountable for ensuring time is set aside to resolve this type of tech debt as it’s incurred by design decisions and frequently changing requirements”.

3. Bit rot technical debt

Bit rot tech debt happens over time. When you see copy-paste and cargo-cult programming – be aware. These are its most common symptoms.  How it happens?

With continues layering of technologies and updates system degrades and becomes inefficient. Often it occurs when project is worked upon by several people who might not fully understand the original design.

Expert on how to fix it: “This is perhaps the only type of tech debt that you should try to avoid consistently by continuous refactoring. Strong teams will take the time to understand the design of the system they are working on (even if they didn’t design it originally), incrementally improve the design and clean up bad code along the way. The development team should be accountable for avoiding bit rot tech debt as it’s incurred by individual developers.”

To sum up, tech debt will, and should, always exist in systems. It’s inevitable. The best way to deal with it is to acknowledge it, include it in the conversation on early stages and, after all, pay it.