In this four-part series, we’ll discuss the similar yet distinct terms of technical debt and digital debt. We’ll talk about what they are, and why they’re a problem, not just for IT teams or those selling software, but also for organizations in the language industry.
In IT, we say that technical debt “is the coding you must do tomorrow because you took a shortcut in order to deliver the software today”. In other words, it’s necessary technology work that, in the rush to meet a specific deadline, hasn’t been completed, or perhaps just not to the highest of standards. You could compare tech debt to a low-quality translation. In this case, incorrectly translated terms or unidiomatic renderings can come back to haunt you by being suggested in the translation memory and replicated repeatedly.
You could compare tech debt to a low-quality translation.
In our fast-paced world, some technical debt is a given. And that’s not necessarily a problem… provided it’s well managed. That is if efforts are made to reduce overall tech debt. However, if that essential work never ends up getting completed, things can quickly escalate, and before you know it, you can have a real problem on your hands. Think incompatibility issues, bugs, outages, and effects on speed and reliability.
What’s more, this issue is no longer just cause for concern for the IT department. Technology is a driver of organizational success and tech debt has become a discussion point at the executive level. In fact, a recent McKinsey survey showed CIOs reporting that 10-20% of the technology budget for new products winds up being spent on resolving tech debt-related issues. That’s no small amount. And when it impacts both your bottom line and your ability to compete, it’s not a problem you can afford to have.
What’s the problem with high levels of tech debt?
When IT projects are rushed through, they tend to be created in a way that is “good enough”. This means that the internal building blocks – the code behind the product or program – are cobbled together messily. Generally, the intention is to come back and tidy it all up. But all too often, this gets forgotten, or pushed to the bottom of the pile in favor of more exciting projects or meeting the next big deadline. The issue with this approach is that this creates more work in the future, as developers have to spend a long time coming up with workarounds or trying to reinterpret the code later on. And this takes away from the time – and money – that could be spent on new features or functionalities. In fact, a recent Accenture survey found that 70% of C‑suite executives believe tech debt “severely limits their IT function’s ability to be innovative.”
From a localization company’s perspective, this is a huge issue. We all know how competitive the translation and localization landscape is, especially in times of Covid. To succeed, your company needs to be flexible and be able to quickly adapt to changes in the market. Cumbersome technology systems will affect your ability to do this, preventing you from innovating and moving as quickly as you might like.
Your company needs to be flexible and be able to quickly adapt to changes in the market
At the micro-level, high levels of technical debt can slow down project delivery. Your systems may be slow, may require a lot of precious project manager time to implement workarounds, or they may rely on manual processes. And all this affects your competitiveness, in an industry where speed is of the essence.
How does technical debt accumulate?
So if too much technical debt is a bad thing, how does it end up accumulating? Well, it happens surprisingly easily. One cause is an organizational, departmental, or individual approach to technology work that prioritizes release dates over all else. This approach doesn’t allow sufficient lead-in time to create clean code from the outset, nor the flexibility to go back and tidy it up after release.
Another contributing factor can be when organizations and teams work in silos. This can happen when developers are only concerned with building the feature or product and don’t consider how straightforward it will be to maintain or how easy it will be to use, since that may be down to the operations and PM teams, respectively. This also comes back to an overarching organizational mindset, as well as to teamwork. If instead these teams worked closely together or understood each other’s needs, this would be much less likely to happen.
Poor planning can also lead to significant amounts of technical debt. When features or products don’t have clear requirements or the scope of work hasn’t been clearly defined, the internal workings of the solution, or the code, can often end up just as messy as the project itself. Similarly, if there haven’t been sufficient resources allocated to the project, the team can become overwhelmed, causing them to rush and quickly pull something together, rather than taking the time to think through the different options or refine their approach.
An example from the translation world would be a poorly planned translation project. If there’s insufficient time or vendor resources allocated or a lack of information or clarity, this can lead to frustrations at every stage of the workflow, and ultimately, to a low-quality translation. And this could spell the end of your work with that client. Or perhaps you may continue to work with this client, but unless you take the time to implement well-thought-out workflows, realistic deadlines, and get all the information you need, the same problems will crop up time and again.