Discussions between development and product management about technical debt are good and important, since not every technical debt needs to be paid directly. In fact, what is relevant and what is not is best determined in a joint discussion. However, it is striking that even experienced developers have difficulties in communicating the benefit of reducing technical debt well. Product management often focuses on the costs without recognising the benefits, which naturally leads to a clearly defensive position.

An experienced and well-established team with a high level of trust and mutual respect from development and product management, as well as the necessary seniority and experience, can certainly do this. However, many - if not most - teams are not at that level. There is a lack of seniority and experience. Individual developers feel they are not allowed to refactor. Everything is so urgent that refactoring issues just keep falling to the back of the list.

Technical debt thrives particularly well in environments with certain characteristics. Lack of experience in software development within a team and missing awareness of the importance of good, easy-to-understand code are for example strong drivers. Too much pressure to implement features fast, as well as too much bureaucracy that discourages individual initiative, are other contributors that impact a team and quickly result in technical debt. In a nutshell, people, their skills and their cooperation within and across a team are the key factors for the build-up but also the reduction of technical debt.

What is technical debt? In a nutshell, technical debt is unnecessary complexity in code. Not to be confused with the essential complexity imposed by business requirements. Unnecessary complexity makes every new feature and every change a little harder to develop than it needs to be. The higher the unnecessary complexity, the harder it is to understand the code, estimate the effect of changes, and test the code. All this slows down further development.