Anyone who works in the field of software development or has come into contact with it has certainly heard of technical debt. The term is often used by developers themselves to draw attention to shortcomings in their work, which are often caused by decisions made by third parties and have a limiting or sometimes even critical effect over time.
Technical debt can be defined as the expenses and costs incurred by applying an incomplete or improper solution or by its subsequent elimination. In other words, it reflects the price paid for the fastest, cheapest or poorly managed version of a product or service after the fact. Technical debt has the unpleasant habit of appearing silently and unnoticed at the beginning and growing exponentially over time to become sometimes crippling. Successful technology-driven companies, and in particular successful technology-driven start-ups, are characterised by effective management of technical debt.
In the digital age, entrepreneurs and executives need to be familiar with this term, its causes and effects and to be able to categorise it appropriately. This applies not only to those working in the software industry but also to everyone else. After all, there is hardly a company that does not use digital solutions or have them customised. In most cases, it is the decisions made and responsibilities taken outside the development divisions that lead to the creation and often improper handling of technical debt. In addition, many companies are investing heavily in new technologies, applications, and systems as part of their digital transformation. Those who do not have an effective approach to managing technical debt in this phase will quickly create problems for themselves in the future.
How technical debt arises
To help entrepreneurs and managers deal with technical debt effectively, it may be useful to divide the potential risk factors for the occurrence of technical debt into two categories. The first category of factors should be addressed primarily within the technology divisions. There should be an adequate basic understanding of their nature and impact to be able to assess and manage the persons or service providers involved. The other category relates to factors that primarily arise and are the responsibility of those outside the technology divisions. Here, entrepreneurs and managers should fulfil their cross-divisional role and have an appropriate level of sensitivity.
Risk factors predominantly within TECH
Quality and style: The clearer the guidelines for the code style compliance and the quality features, the lower the risk.
Modularity: The more appropriate the flexibility of software code is or the less it is limited by monolithic structures, the lower the risk.
Tests: The more effective the regulations for performing tests and acceptance procedures, the lower the risk.
Documentation: The more effectively and comprehensibly software code, acceptance criteria or architecture are documented, the lower the risk.
Updates: The more planned and consistent the so-called refactoring of existing software code to improve interoperability with other components, the lower the risk.
Risk factors predominantly outside TECH
Requirements: The clearer and more measurable the requirements for the solution and the more transparent the definition of changes and improvements, the lower the risk.
Complexity: The more conscious attention paid to limiting complexity and avoiding so-called over-engineering, the lower the risk.
Timelines: The more realistic and justified the expectations for the development period, the lower the risk.
Compromises: The more consciously and honestly compromises are made during implementation, documented and dealt with afterwards, the lower the risk.
Empowerment: The more effectively the teams involved in the solution work together and the greater the transparency and involvement, the lower the risk.
Any entrepreneur or manager with sufficient experience, honesty, and self-reflection will be able to place the above five factors outside of TECH in their specific business context. Probably the least favourable approach is to deal with the many good reasons that justify the emergence of these risk factors. Probably the more effective approach is to recognise this and deal with them in a targeted manner. Technical debt occurs wherever there is a lot of development and the world is as described by VUCA. This is why it should not be tackled from the outset, but intelligently managed and consciously limited. Using this approach, technical debt can also be categorised into the following four quadrants:
| ➟ | Knowingly and recklessly accepted - We could act differently, but there is no time to lose... |
| ➟ | Consciously and prudently accepted - We know there is another way and we will fix it later... |
| ➟ | Unconsciously accepted without reflection - We have decided to do this because of a lack of ability or ignorance... |
| ➟ | Unconsciously planned - We assumed at the time that we were implementing the most effective solution... |
When technical debt makes sense and when it does not
Like financial debt, technical debt is not generally bad or to be avoided. It depends on how you deal with it and, like financial debt, whether it pays off in the end. There are situations in which technical debt is consciously incurred and has a positive effect. For example, the rapid introduction of a so-called MVP (minimum viable product) can have the advantage of avoiding short-term customer losses. It can also fulfil the most urgent needs, obtain initial feedback and implement the necessary follow-up work during the resulting temporary customer loyalty. It may even make sense to use such an MVP to initially determine the balance between market requirements, customer demand and product functionality. Such validation can be used to decide whether the solution should be discarded or whether more time should be invested in improving the MVP. Unfortunately, a frequently encountered variant is that an MVP introduced under excessive time pressure becomes the permanent standard application.
Technical debt should be avoided wherever standardised products are to be scaled. Either it represents a noticeable impairment from the outset or it scales with the growing production volume, so to speak, and is ultimately difficult to eliminate with reasonable effort. Another risk that should not be underestimated is the interlinking of many small- to medium-sized technical debts within process chains. If an end-to-end process involves 7 teams with a total of 12 sub-processes and different systems, even the multiplication of two small and one medium technical debt can have a massive impact on the result and the customer experience.
Dealing effectively with technical debt
As in many areas of Enterneering®, dealing effectively with technical debt requires the necessary degree of awareness, honesty, and openness. This means that the elements of value systems, transparency, communication, involvement, and knowledge also play a major role here. Companies that are already effectively positioned in these areas will be able to deal with technical debt more quickly.
Any form of targeted handling first requires knowledge of the type and scope of technical debt. A list (list, table, backlog, system) is therefore a mandatory prerequisite. If possible, this list should be created in such a way that it can be regularly reviewed and updated, and it should ideally contain evaluation criteria. Based on these criteria, the impact, significance, effort and consequently the priority should be derived and provided with clear treatment measures. Within software development, code audits or code reviews are used for recording. Such an instrument should be anchored in technology-oriented companies as a continuous process within the company.
Furthermore, the management and corporate culture should continue to develop in such a way that the occurrence, relevance, and handling of technical debt are discussed objectively and, in a value-oriented manner. An essential prerequisite for the successful handling of technical debt is a clear understanding that it is a debt that needs to be repaid, which results in expenses or costs.
Technical debt outside of TECH
Looking at the topic described above from a slightly more distant and less software-focussed perspective, you can quickly identify other areas in the company where similar ‘debts’ can occur. In the context of digital transformation, this broader view is certainly valuable because it covers other important components that are not primarily associated with software development but have a comparable effect. This includes, for example, systems or processes that are inadequate or do not perform well or function incorrectly due to decisions that have been made or due to decisions that have not been made but are overdue. It is also important for management to be aware of this and to fulfil the responsibility and role of enabling the organisation and the people working in it.
Summary
Although the term technical debt stands for work in software development that needs to be completed, changed or corrected, it can be applied to various areas in the organisation. This type of performance backlog arises wherever development work is incomplete, incorrect, or outdated because of decisions that have been made or delayed. As an entrepreneur and manager, you are well advised to deal with this issue consciously and authentically. Make it clear within your organisation where you stand on the issue, and what your expectations of the organisation and those responsible are. and what you are specifically doing to ensure that technical debt does not become a threat to the company. Also reflect on your own decisions and judgements, which may also lead or have led to technical debt.