Forget about technical debt and finally start delivering

The concept of technical debt has become a convenient punching bag that we hit when something goes wrong, completely ignoring the fact that it is just one leaf on a huge tree of problems. If we want to realistically change our everyday life in IT, we need to stop fixating on the code itself and look at what it does to our brains.

Why cognitive load is your real enemy

Technical debt hurts us not because the code is ‘ugly,’ but because it increases our cognitive load. The more hooks, unclear abstractions, and outdated solutions there are in the system, the more we have to keep in our brain's cache to make the simplest change. It is this mental burden that causes estimates to rise and makes us feel burnt out after eight hours of work. Instead of focusing on ‘cleanliness’ for the sake of cleanliness, we should ask ourselves: how much does this piece of code burden the processor in my head?

The tree that hides the whole forest

Focusing solely on technical debt is a trap, because it is only one of many factors that influence how quickly we deliver functionality. Poorly defined business requirements, constant meetings that disrupt flow, or a lack of adequate DevOps platform support can kill efficiency much more effectively than an old module in legacy code. Interestingly, some studies suggest that as much as 80-90% of requirements in companies do not bring any real business value. This means that we are producing technical debt by building things that no one needs. Do we even measure whether a given feature is actually used?

The database as a silent killer of flow

We observe a similar phenomenon in data architecture. We often complain about slow queries, but we rarely think about how a complex schema affects our understanding of the system. Overloaded tables and lack of consistency force us to write monstrous queries that are difficult to maintain and debug.

How to stop chasing your own tail

Technical debt is not just an IT problem, but a problem for the entire organisation. It cannot be repaid if the business provides ‘fuel’ in the form of unrealistic deadlines and changing visions on a daily basis. The stress we work under activates the ‘fight or flight’ mode in our brains, drastically limiting our analytical abilities. As a result, we write worse code, which generates more errors, which in turn increases stress. It's a vicious circle that we cannot escape with SonarQube or automatic metrics alone.

Instead of fighting over every line of code, let's start talking about debt in terms of risk to production stability and implementation costs. We need to educate people outside of IT that their decisions – such as putting too many tasks into a single sprint – have a direct impact on technical quality. Only a holistic approach that takes into account the well-being of engineers and the purity of business processes will allow us to really accelerate. Forget about technical debt as an isolated problem and start making sure that the system allows you to think calmly.

Happy retrospective-ing!