Nobody intentionally creates technology debt. It accumulates as a result of rational, short-sighted decisions to deliver value now rather than in the future. A quick hack to meet the deadline for a trade fair launch, a work-around because the approved solution would have needed a substantial budget line, a customisation that was poorly documented because it was only a minor adjustment – all these decisions can be entirely reasonable at the time. However, years later, they combine with hundreds or thousands of similar adjustments to drastically increase the costs and risks of any future software change.
The comparison to financial debt is not accidental – technology debt shares many traits with it, including some vital aspects that are often ignored, with serious consequences. This article explains how technology debt manifests itself in day-to-day operations and what warning signs to look out for. It also describes ways to begin addressing it, including choosing between quick wins and large-scale but gradual reorganisation.
What Technology Debt Is
Technology debt, sometimes called technical debt, refers to the collective costs of software and infrastructure shortcomings that reduce the speed and quality of future development. Technology debt manifests itself in many ways – the most common ones include code duplication, poor test coverage, overcomplicated logic, inconsistent APIs, and other issues in the source code. It is not limited to it, however – business processes, data structures, and even paperwork can contribute to technology debt, albeit indirectly.
Technology debt is not always bad – deliberately incurred debt allows one to accelerate time-to-market and test ideas without significant long-term costs if it is repaid. However, it frequently happens that the debt is not repaid due to pressure from management to deliver more features or changes to the system within the existing capabilities. Some of the most dangerous types of technology debt do not even have an obvious source.
Warning Signs in Operations
Most warning signs of technology debt are common sense to anyone who has to operate or maintain the software on a regular basis.
Quick and Simple Changes Take Too Much Time
A request to add or change something simple takes significantly longer than one would expect, considering the available tools. A new field to fill, a price list adjustment, a shipping option – changes like these take weeks instead of days because different parts of the system are highly intermingled, and there is no automated testing, which means every modification requires manual verification. Inconsistencies in logic may lead to simple adjustments having far-reaching consequences.
Revisions Are Big and Rare
Big releases that take considerable time to prepare and deploy are the norm – and they are always rescheduled to outside working hours. System updates that require changes to the software are rare, and even then, they are “hotfixes” applied immediately after discovery. There are “do not touch this subsystem” instructions that everyone obeys, rollback procedures that are executed too often, and “production” versions that are significantly different from what is used during testing.
People Are Required to Be Available
Some people seem to become unavailable at the worst possible times – on vacation, sick leave, or shortly after a promotion. Everyone else holds their breath when such a person is on leave because the only person who understands how system X works is away. This is another debt that is frequently poorly tracked – it is not visible in the software, but the loss of institutional knowledge can be catastrophic when an employee leaves.
Workarounds Are the Norm
People use Excel sheets to process orders, data is re-keyed from one system to another, or orders are manually transferred between systems in order to finish a task that the software is supposedly capable of doing but is too difficult to utilise. These workarounds consume time and effort, and they all have their price – whether it is extra hours spent on the task or the risk of human error.
The Same Bugs Keep Occurring
When a bug is fixed, but it keeps reappearing in a slightly different form, it indicates that the underlying cause has not been addressed. It is frequently much harder to deal with the consequences of the bug than to prevent it in the first place, and this leads to recurring issues and an expanding support knowledge base.
Warning Signs in Technology
Some warning signs require deeper investigation, but it is worth conducting this review at least once a year.
Out-of-Support Technologies
A database, operating system, or programming language that is no longer supported by the vendor. It is critical to understand that end-of-life (EOL) software is unable to provide the necessary level of security, especially for processing personal data under the DSGVO. This is a particular concern for companies that handle personal information, although it is not the only consideration. For example, some industries have specific requirements for technologies and software used in their systems, and the use of unsupported software may violate contracts with clients. Consult your data protection officer and legal counsel to determine the appropriate course of action in your case.
Outdated Technologies
Program libraries or programming frameworks that have not been updated for several years – if one has to update them, it will require substantial effort. Systems that cannot be integrated with modern Softwareentwicklung Deutschland, or that only exchange data through file imports and exports.
Performance Issues
Systems that perform poorly and require workarounds – long downtimes, scheduled restarts, rate limits on reporting systems, or other adjustments to hide their shortcomings.
Lack of Infrastructure**
The ability to rebuild the system from scratch is hampered by the fact that it was initially set up incorrectly or no one knows how to do it.
Warning Signs in Business
Technology debt ultimately manifests itself in business processes and decisions.
There are features that the company would like to implement, but they cannot do so because “the system does not support them”. New sales channels and distribution chains cannot be launched because “the ERP is not ready” or “we cannot integrate it”. Customers ask for an interface, a portal, or other access to data, but it always takes too long. People leave the company because they are constantly fighting with poorly designed systems, and it becomes harder to hire new people – or they only arrive to find that their skills are wasted on legacy software. End-users are frustrated with slow, unreliable software and take their business elsewhere – or create shadow IT to solve their needs.
Assessing Technology Debt
An initial assessment can be made without a large-scale audit. A brief analysis performed by the staff responsible for the systems under review can identify most critical issues.
A list of systems critical to the business should be created. For each system, information is collected on its age, the date of the last update or significant change, its support status, the people who understand how it works, how often it is changed, and how much time is spent maintaining it. For each system, staff members responsible for it and capable of making changes to it should be asked what the three most pressing issues with the system are. Finally, these lists can be compared – it is often surprising how little consensus there is about what the main problems are.
Each system should be prioritised based on two criteria: its business significance and the number of problems it has. Particular attention should be paid to systems that are critical to the business but have many issues. One should also consider what to do with systems that are not important but consume resources – perhaps it is time to retire them. Finally, there may be systems that are old but do not cause many problems and are rarely changed – in this case, there is no particular reason to rush to replace them. Age is not the only factor that determines technology debt, and stable, working software that rarely requires changes should not be replaced simply because it is old.
Addressing Technology Debt
There are many approaches, ranging from incremental improvements to large-scale rewrites. Most companies find that a combination of small and large-scale changes is the most effective, depending on the situation.
The simplest way to begin repayment is to allocate some development resources to addressing technology debt on an ongoing basis. This allows one to gradually pay off accumulated debt without making large changes to the existing processes. However, this approach alone is insufficient to address substantial problems with production systems.
More significant issues require more comprehensive measures – modernisation of individual components, replacement of certain technologies, or even partial rewrites of subsystems that are too old or poorly structured. Sometimes, the most viable option is to move to a new platform or software that is capable of supporting the necessary processes. If the software encodes business processes that are unique to the company, this may require individuelle Softwareentwicklung. However, one must also consider long-term costs and potential future debt.
The capacity of development teams is frequently the limiting factor in technology debt repayment, where the people who know how to maintain legacy software are the same ones who must rewrite it. In some cases, external help is required to address particularly persistent issues, and Outsourcing Softwareentwicklung can be a viable option, particularly for well-defined tasks. However, it is critical to ensure that knowledge is transferred to internal teams so that they do not become dependent on external contractors.
Repayment as a Business Decision
Technology debt is reduced when business decision-makers understand the opportunity and cost. It is essential to highlight these considerations when discussing technology debt repayment with management.
It may be helpful to estimate how much time is spent on average on changes to production systems and how much of the IT department’s capacity is consumed by these changes. It is equally important to examine how much time is wasted on workarounds and what risks are incurred due to system shortcomings. The opportunity cost of these expenditures should also be considered – what other initiatives could have been undertaken if not for the technology debt?
A reasonable starting point is to select one system and calculate its impact. Estimate how much it costs the company on average per month in terms of staff time and risk, and compare it to the cost of addressing its most pressing issue. If possible, consult an external expert who can provide an independent assessment of the system’s state and the scope of the required changes. Otherwise, ask your team what workaround they would eliminate first if given the opportunity.
Top comments (0)