Companies around the world adopted new technology to support remote workers and fast-tracked digital product releases in response to the pandemic.
This shift provided agility, but for many companies it came at a cost: soaring technical debt.
Nearly eight in 10 companies took on more technical debt in the last year, while only 6% have taken on less, according to a recent report by Software AG based on a survey of more than 738 IT leaders.
For 56% of companies, the additional technical debt was necessary to adapt to changing times. Another 48% said taking on technical debt was a deliberate act to quickly capitalize on a new opportunity.
"This was the sensible time to do it. That's what debt is for – to get you through tough times," said James Uther, senior engineering lead in Oliver Wyman's digital practice. "Organizations made a lot of quick changes, with new applications and new management systems. But now they have to pay back that debt."
Failure to address backed-up technical requirements can mean companies delay their innovation cycle, devoting resources to previously ignored issues instead of serving the future needs of customers and employees alike.
Technical debt can be worth it – but there's a limit
Just as someone might take out a loan to buy a car instead of saving for an all-cash payment, an engineering team may ship a product even though some of the code is immature, or an IT team may launch an application now instead of spending months to integrate it with backend systems. This sums up technical debt.
In some cases, technical debt is worth it. In the Software AG survey, 95% of companies who took on technical debt to support hybrid work said they would do it again, while 86% said their technical debt was justified since it led to a faster product launch.
The downside, as with financial debt, is taking on too much debt or taking too long to pay it back.
The longer the immature code goes without a fix, the more likely it is to break. The longer the enterprise application sits in a silo, the greater the drain on productivity as employees manually transfer information or toggle between multiple systems.
"As systems get old and complex, people may not understand what's running inside them, they may not know the full capabilities, and they don't know what will happen when it changes," said Matt McLarty, global field CTO and vice president of the digital transformation office for Mulesoft.
If a company needs to take on a big project, such as an enterprise resource planning (ERP) system overhaul, it can often be hard to make the time for it if there's no new business value, he said.
Acceptance is important – but so is management
Much like financial debt, technical debt is difficult to avoid. In fact, according to Software AG, more than eight in 10 companies said the pandemic increased their awareness and acceptance of their own technical debt.
Acceptance is an important first step, said Dean Faulkner, partner and head of engineering for Oliver Wyman. "Technical debt can't be considered a dirty, evil thing," he said. "What's worse than technical debt is an engineering team chasing something that won't have any. That's more inefficient than taking on the technical debt."
After acceptance, though, must come measurement and management of technical debt. The Software AG survey suggested companies appear to be more confident in the ability to do the former: 82% of those surveyed said they can assess most or all of their technical debt, while only 58% have a formal strategy for managing it.
That comes at a cost. Technical debt made up nearly 25% of IT budgets in 2021, and more than two-thirds of companies expect to spend more in 2022. A similar number said technical debt has caused their digital transformation initiatives to slow down.
"Technology companies can manage technical debt well, since all managers are tech people, but most organizations don't have a high-level leader who knows code," Uther said. "They know things are getting slower and slower, but they don't realize how much technical debt they're taking on."
Open standards, abstraction, and incremental change can help
Analogies to financial debt explain how best to manage technical debt. If someone has two loans that are all currently interest-free, and interest kicks in at 20% for one loan but just 1% for the other, then it makes sense to focus on the first loan, Faulkner said.
"You need to take the time to understand the prominence of the debt and deal with it accordingly," he said. "It could be engineering, but it could also be requirements changes. And then you have to have an acceptable discussion about what is your acceptable technical debt."
Proactive steps can also help minimize the downstream impact of technical debt. One is to adopt open standards, Faulkner said. This will limit the need to redefine processes or customize integrations.
Another is to embrace abstraction and move away from tight vendor lock-in, Faulkner said. "If you pay vendors to do independent integrations, then you get locked into their data model, and you can't move outside their systems," he said.
Companies can avoid this by requiring any outsourced technical work to not only meet functional requirements but also to align with their own architectural governance principles, according to Faulkner.
For companies trying to manage the technical debt associated with legacy systems, an incremental approach works best, McLarty said.
"We have decades of proof that big-bang replatforming is doomed to fail," he said. "That's because it's not the system that's hard to replace, but the data behind it. If you have an entrenched system, you need to find the one path in and then migrate gradually."
