Innovating with the brakes on
It is of course true that the sooner you tackle and resolve problems, the simpler and cheaper they are. For example, a bug fix at the beginning of a project costs just 10% of a bug fix at the end. Or vice versa, the longer you continue to push out certain issues, the more complex these become (exponential factor 2.1) and the more they cost. You may even reach a point where they cannot be resolved. In this way, technical debt slows down progress, and that’s something you should try to avoid at all times. Especially when digitalization and modernization are a prerequisite for survival.
A company that spends more than half of its IT budget on integrations and 'repairing' legacy systems is likely to end up in a technical debt spiral in which it only pays interest, due to the IT legacy from the past. When a company operates on a modern IT stack and has few technical debts, almost all of its technological investments can focus on future-oriented solutions and strategic innovation, and thus create added value for the entire organization. Most companies are somewhere between these two extremes. What it boils down to is reconciling short-term and long-term – running the business and changing the business – in a positive digital flow.
Watch out for the elephant in the room
It has to be said, technical debt is not necessarily a bad thing. Incidentally, you can never completely exclude or prevent technical debt. Projects need to be able to make progress and you’re faced with certain deadlines or temporary constraints, which means you have to change gears and sometimes take a shortcut.
However, it is important to be aware of the technical debt you are accruing and plan to do something about it with every choice you make in the development process. In this way, the level of technical debt remains acceptable and the short-term solution or shortcut can be converted into a structural solution in a reasonable period of time. Technical debt should not become a blind spot or the elephant in the room that no one wants to see.
Nevertheless, there is often a discrepancy between awareness and effective action. A study conducted by McKinsey1 shows that CIOs are well aware that there is technical debt within their organization and that it is increasing. In practice, they actually spend little or no budget on doing something about it. As a result, they burden the organization with a technological legacy that can sometimes be very difficult to get rid of. The study also shows that if budget is spent on technical debt, it will more likely to go to new projects in order to prevent the accumulation of technical debt there, and less to older legacy applications.
Where does technical debt actually come from?
The origin of technical debt can be found at different levels: strategy, architecture, talent and processes. For example, a strategic driver may be that a company’s business strategy has not been properly clarified, so the IT department does not know how to deal with this or how to preclude it. Maybe IT and strategy are not aligned well enough, so the focus is on the wrong IT initiatives. Or there is a mismatch between financing and strategy, in the sense that you want to do something but don't have the funds for it. Strategic acquisitions and takeovers can also increase the complexity of the IT landscape and processes, with all the associated risks of technical debt.
On the architectural front there are also parameters that play a role and can give rise to technical debt. It's said that 70% of IT systems are still running on outdated technology. In other words, there are still quite a few legacy systems in the application landscape of an average organization, and in any case they continue to generate costs for the business. Heavy customization and monolithic blocks of code can also drive technical debt, as well as poor data models and data quality or not using standards and APIs.
In addition, software is still mainly made by people. Lack of knowledge, skill and even motivation can also be a cause of technical debt. Teams that do not work well together, or even not at all, so one team creates technical debt for the other.
Finally, there are also internal processes that can be a cause of technical debt. Poor prioritization of things to be developed, poor development and maintenance processes that result in poor code quality. For example, there is little automation, so a lot of test work still has to be done manually, which increases the risk of errors. Unstable IT operations, poor disaster recovery, inadequate monitoring, conflicting or missing documentation can also lead to IT teams working blind, and thus generate technical debt.
