Technical Debt - what it's all about and how to prevent it

Ohh it's that time again. What is technical debt? What are the consequences of it? Is technical debt a bad thing? We will answer all these questions (the answer to the last one is yes btw). But first, let's talk about...

What is technical debt?

It's basically just an metaphor designed for non technical people, to clarify the issue with not fixing bad code right away. It goes something like this:

Writing bad code is like going into debt by taking a credit. You get a lot of benefits right now, but you have to pay it back PLUS interest.

Like taking a credit is not always a bad idea, technical debt is the same.
But at the same time, it's like a taking a credit. It's often a bad idea :).
There are scenarios where it might be a valid decision to take this metaphorical credit, but we'll talk about this in a bit.

Why do we need such a metaphor? Everybody knows: bad code is bad code!

Although there is nothing that I'd rather do, than live in your world, I have to crush your reality. Just because the term "bad code" explicitly tells people, it's a freaking bad thing to do. There are people that think it's not that big of a deal.

I'm talking about management people that decide to hurry the software development teams to fulfil the customers' dreams faster.

What happens when technical debt is build up?

At first, the management people get the desired outcome. They take the credit and get the money, so to speak. The features are build faster and they can ship releases more often.

But this comes at a price. The code gets messy, because "we don't have time for good design". And so each feature that comes to the messy mountain will take longer and longer to implement.
Until the system is at a point at which you need months to implement a single feature.

There are statistics (link in the resources section) that state: Over the course of a project, the time to implement a new feature increases up to the 60x-100x compared to the initial rapid development phase.

Consequences of technical debt

On the software development layer, you basically have three simplistic issues by building up technical debt, that will later express in more business related issues.

more bugs
it takes more time to build features
it becomes harder to refactor and more dangerous, every day.

But what does this mean to the business?

In the worst case this might mean bankruptcy. But there are steps before:

outages, that might lead to a financial damage because of signed service level agreements
security issues, that might lead to a reputational and a financial damage
impossible to react to changing requirements, because it's almost impossible to refactor a thing without breaking something.

The four types of technical debt - Technical debt quadrant

One can draw the technical debt as a quadrant, a table with two columns and two rows. The illustration from Martin Fowler of his blog post: Technical Debt Quadrant shows this very good.

Reckless and deliberate is by far the worst reason to build technical debt in my opionion. It's just ignoring the fact, that the software will become a nightmare to work with and the quality will fall day by day.
Reckless and inadvertent occur quite often. It's when you just don't know better and don't know the consequences of technical debt. This can be fixed by learning a bit more about software design.
Interesting things happens in the Prudent row. Prudent and deliberate CAN be the only valid reason to build technical debt. I write CAN, because it's only ok if you have a plan to pay the technical debt back and you will stick to it.
It might occur when you have tight deadlines to win a deal for example and need to finish that proof of concept as fast as possible.
Prudent and inadvertent is by far the most interesting one and nobody can escape from it. You know that you are building technical debt, but you just don't know the perfect approach for it.
So you are taking the one that looks good to you and one year after that you revisit the snippet and find out: It could have been done differently.
You're always smarter in hindsight.

The only theoretically way to deal with prudent and inadvertent technical debt

Fred Brooks came up with the idea to build a system for a specific period of time and then throw it away to rebuild it. I must confess, I think this would work regarding the better software quality.
But since we are getting paid for our work, our customers don't like waiting and our competition doesn't sleep, we won't get the indulgence to approach this solution.

In other words: you won't fix that one in our world.

Conclusion

The technical debt metaphor is a great tool to convince our managers not to hurry and grant the time for great features to finish development phase.
It's also not always bad to build technical debt, but almost always. And don't forget that there are four types of technical debt that are often drawn as Quadrant.

AND SUBSCRIBE TO THE NEWSLETTER!!