If there is a topic I’m sure that every engineer was come across with, is TECH DEBT. No matter if you are working in a 8 months startup of a 25 year old enterprise, you know what it is (or at least kind of), you’ve heard conversations on the retros and most likely they were repetive.

What is tech debt?

Okay, but why would a company even care about it?

Is a questions that may engineers of very different levels need to respond when they raise a topic like this.

Usually the person in front has this thought processing and most likey is from a different business unit -> If we use time to solve tech debt -> We don’t release features -> If we don’t release features -> We don’t generate some type of impact (the type depends on the team) -> Then WHY?

Okay, let’s take a step back, undertsand what they are trying to say, and make our point:

As a very general way, every tech compnay tries to solve a problem that people are willing to pay for and uses tech as the enabler to solve the problem. Probably by tweaking this sentce a bit almost every compny could fit here.

The tecnology enablement side is what tech debt is about. Can we sustainalbly build that product? If we look at for exapmle DORA metrics {LINK THERE} the goal is to balance speed and operatinalty. and an extreme tech debt is not going to allo us to do that.

SO, to the previous though process, well the system is just not linear: to create new features sustiainbly, we need to have a reasonale amount of tech debt.

Should we avoid tech debt?

I’m not sure of that is feasible, but I’m pretty sure is a bad idea.

Another key idea is that the Reasonable amount changes with the size / type of company [LINK HERE]. I prefer the idea of changes with the mission of the team.

Practical Advice for Practitioners

References & Further Reading

1. Cognitive Load Theory for Software Development
   https://thevaluable.dev/cognitive-load-theory-software-developer/