The term “technical debt” is misleading:

  • there is a feeling that something needs to be given
  • there is a feeling that this is real.

In fact, neither the first nor the second is true.

What is technical debt? This is something that is not directly related to the product features, but causes us some pain. Examples:

  • the PO of technology specialists is higher than that of competitors (Oracle?)
  • the technology is already so outdated (Cobol) (or vice versa is so young) that it is difficult to find ready-made specialists in the market (and just ready to teach it)
  • the product is unstable
  • during security audits, they constantly find a lot of problems and it is unclear how to “normally” solve it
  • the code or technology is too complex: it requires more qualified employees and more time …

Sometimes technical debt is considered more narrowly: as something that degrades the development experience. This is the usual position of developers. A narrower interpretation also does not affect the need to give and the ability to give everything.

The main groups of problems can be distinguished:

  • non-functional (speed, stability, system requirements, …)
  • HR department: difficult to find, expensive to find, often get fired, motivation drops quickly
  • lawyers: effective compliance with legal requirements, questionable licenses
  • security guards: if possible, a solution to the problem at the technology level, quick security updates for technologies
  • UX: if possible, a solution to the problem at the technology level (especially accessibility functions for people with disabilities)
  • dx (developer experience): slow to write, change in a bunch of places, fragile code, etc.

Is it possible to pay off the entire technical debt? No:

  • it’s very expensive
  • this will stop product development, which means, in many ways, an increase in sales
  • even if we try to do this (we stop development and go through the created tasks of technical debt), we will realize that we can write as many more tasks (no less lengthy, but, hopefully, less critical). I.e., it is endless.

If the debt cannot be paid, then this is already a misnomer. “Technical imperfection” is much more appropriate. Everything is already clear here: yes, something is wrong, but perfection is unattainable, we need to look at what is really bothering us now, and only fix it.

Programming is in many ways a craft. If a person does not have the skill (even just knowledge is often not enough), then he produces low-quality code (relative to an experienced person). Similarly, a weak programmer often reduces the quality of his code in order to keep up with a strong programmer in the team. All this may be acceptable, maybe not. So, there is a technical debt that arises simply from the development of the product and technology, and there is from the imperfection of people in the team.

From time to time, there is an approach when they first program with reduced quality, and then take separate sprints to improve it. If there is some business sense in this (for example, to be in time for the opening of the exhibition), then it’s fine. If there is no such sense, then it rather harms: bugs are fixed the easier / faster the fresher they are.


  1. Technical debt is a disgusting term. Technical imperfection is better. It is even better not to use it at all (and not to think in this term).
  2. The concern of technical leaders is to identify business needs in time (primarily unproductive ones, since specially trained people identify grocery ones).
  3. It is also the task of technical leaders to set quality standards for the company, products, and individual features. And update them in a timely manner, because the situation changes over time.
  4. Identified needs are transformed into tasks and prioritized.
  5. Another option is to train people, introduce automatic auxiliary and verification tools. This also includes changing work policies: this is an option for a long and slow reworking of the existing code base. Long and slow is not only a minus, but also a plus: there is progress, it is gradual with a set of experience (and therefore more effective), there is no complete shutdown of other tasks.