Technical debt affects almost every organization, cuts into productivity, drives down profits and inhibits efficiency. Worse, it represents an often unquantified and unconsidered risk that can cause outages, direct financial losses and reputation damage. Fortunately, it can be fixed — and usually money can be saved fixing it. In this post, we’ll introduce the concept of technical debt and consider what it looks like on the ground, as well as considering the forms it can take. Then we’ll talk about how to remedy it.
First, let’s define it.
What is technical debt?
Technical debt is sometimes also referred to as design debt or code debt, and can refer to hardware and other technical elements as well as to software. In software, technical debt refers to the costs an organization will face to bring its software up to a standard that’s appropriate for the company’s growth stage and other requirements. For instance, a small company might choose a small, simple, limited solution — in many cases, a generic of off-label tool. Later, when the company grows, gains larger customers with more complex demands, or the load on that solution increases in some other way, it turns out to be both inadequate and impossible to scale.
What does technical debt look like?
Technical debt at the level of hardware selection is extremely common in small businesses, for instance. Many have too few computers for their IT needs, and those computers are often old. They run outdated versions of common consumer operating systems. As of 2019, 41% of small businesses surveyed by Kaspersky were running Windows 7 or Windows XP. Both OSs have now been unsupported for many years.
While these teetering IT solutions remain barely adequate for managing the day-to-day demands of a small business — spreadsheets, documents, and so forth — they represent huge data vulnerabilities because security issues are no longer patched. And eventually backward compatibility runs out; outdated software must be replaced, but the old operating system cannot run the new version; it too must be replaced, but the outdated hardware can’t install the new OS. The business suddenly can’t calculate payroll or make notices to stick on the wall, and has to buy and set up a new computer system just to return to normal functioning.
This is technical debt: problems accrue behind the scenes, while users McGyver their way along with make-dos and workarounds. Eventually the edifice crumbles and the business suffers outages, attacks, or large unexpected costs. In the meantime it pays in risk, reduced operating capacity, and damaged reputation.
Obviously in the world of high-performance business software, and rapid-growth startups, things are completely different.
Except it turns out they’re actually not that different.
Technical debt at the software selection level
When fashion brand LuLaRoe started out, they had three retailers and used a manually updated Google Sheet to track inventory. When the company scaled to 80,000 retailers they continued to use a manually updated Google Sheet to track inventory. It’s easy to imagine an increasingly large number of FTE staff devoting an increasingly large number of work hours to CTRL+C and CTRL+V as the company’s sales and inventory expanded. Obviously, such inefficiencies are what software exists to solve.
However, this type of technical debt is relatively easy to spot from the outside and fix, providing the company is amenable to the necessary software purchase, implementation and consultancy. It can very easily manifest in other ways, including a kind of diffuse, ‘shadow’ technical debt where end users are responsible for the problem because they can’t or won’t use the solutions provided. This is a commonly-recognized problem in sales and it’s worth looking at how it works there, because it’s an extreme case of the wider problem.
Other types of technical debt
Sales leaders arrange for the purchase and implementation of CRM (Customer Relationship Management) software, and require sales staff to update it. But sales staff hate updating it because it takes a lot of time. Often they can’t finish one call and start another until they’ve updated their CRM, or they’re required to enter information they don’t have. These staff work on commission, so work that doesn’t lead to sales costs them money and they don’t see a connection between record-keeping and sales. The result is, they work around the system instead of through it, and the company is no better off than when it bought the software. It still can’t make accurate strategic decisions on the basis of its data because its data quality is too poor.
The solution to this problem is to convince end users that using the software does speak to their interests; in this case, for instance, better record-keeping does correlate with better sales, especially in the long term. Users need to be engaged, to learn by doing, to be convinced that this is a tool to help them rather than an obstacle for them to outwit, and to see the benefits to them of using it.
This ‘shadow technical debt’ isn’t confined to sales: it’s universal. In 2015, Rebecca Knight told HBR readers that 63% of managers felt the pace of technological change in their organizations was too slow because of employee resistance to new technology; a 2020 HBR piece set out to address the still-live question, ‘Why Do Your Employees Resist New Tech?’ Authors Frank-Jürgen Richter and Gunjan Sinha found that the answer had not changed: employee skepticism was top of the list.
Another manifestation of technical debt is external technical debt, where you’re reliant on outdated technologies that aren’t under your control. Adobe brought thousands of organizations out of such debt when it retired the notoriously insecure Flash Player at the end of December 2020. Prior to this, many software systems had to interact with Flash, despite its known vulnerabilities and shortcomings.
Software technical debt
In software, technical debt typically manifests itself as poor software selection, and poor or poorly-annotated code. Like most forms of technical debt, this one eventually involves payment in cash; the proportion of software spending that goes to maintenance has risen by 20 percentage points since the 1970s and maintenance now accounts for 90% of all software costs.
Of this sum, 50% is spent on analysis of existing software: figuring out what we’re even working with here, before we update or fix it. When software-task fit starts out poor, they tend to creep apart over time, so that an off-label use that worked well enough for a smaller business becomes a serious encumbrance when that organization grows.
Managing technical debt
Technical debt can be managed by prevention, mitigation, and by paying it off.
Preventing technical debt
To prevent technical debt in software, companies should partner with a consultant or purchase their software through a trusted partner that can act as one. The goal should be the best possible fit with both current requirements, and projected future need. For example, businesses that expect rapid growth should be looking for easily-scalable software that’s intuitive, mirrors industry standards, or both; that way, when they pick up new customers or hire new staff, the transition period is short and comfortable. What you don’t want is to outgrow your software right when you’re meeting your goals in other areas, so you need a partner that both understands the software landscape and gets your situation as a business.
In development terms, best practice is to create human-readable, annotated code that meets the standard: can an engineer who has never seen the code before start working on it easily? That’s particularly important with custom code for bespoke products or customized solutions, where the engineer who maintains the code and the one who wrote it may never meet in person.
Mitigating existing technical debt
Mitigating technical debt involves finding ways to reduce its impact, now and in the future. That can mean seeking out technologies that can integrate with the processes you’re already using, while reducing your reliance on workarounds, obsolete or poorly-performing software, or insecure and unsafe systems. Or it can mean rebuilding the tools you’re using while keeping them operational, using CI/CD (Continuous Integration/Continuous Development) engineering to bring your custom software solution in line with your needs.
‘Paying off’ technical debt
Finally, if you have major technical debt that can’t be successfully and economically mitigated, the best solution might be to simply pay up. Go back to prevention, prepare to transition over from your current system, and work with a trusted software development partner to build or customize a solution that matches your business requirements.
The bad news is that this involves some cost and internal disruption — even when the whole process is handled perfectly, staff inevitably have to learn some new skills. However, it’s almost always doable without downtime and, depending on the nature of the software, your customers may never know. The good news is that it’s often possible to simplify and accelerate business processes, even automating some. Instead of using parts of the functionality of several tools, none of which quite does what you need (even though you’re paying for the whole tool), you can end up with a near-perfect tool-task fit, and ongoing support makes sure it stays that way.
Embracing technical debt
Throughout this post, we’ve talked about what a problem technical debt is, and how to manage it. But while it always needs monitoring, technical debt isn’t always bad in itself — any more than financial debt is. Imagine two companies: one is ‘drowning in debt,’ the other is ‘securing investments’ or ‘running on VC money’ or… you get the picture. Sometimes technical debt lets you take the next step now, and pay for it later. Lots of very early-stage startups build an MVP from easily-available tools, resulting in some ugly, inefficient code. They take that to market, then rebuild from the ground up once they can afford it. Without the technical debt, they might never have made it at all.
This can be true even if you’re a more mature business or if we’re talking about a more mature product; everything is a trade-off between getting it perfect and getting it done. Technical debt is dealable-with, and can be the price you pay for an advantage. Just remember to account for it.
How AndPlus can help you manage technical debt
AndPlus has worked on hundreds of digital product development projects, with businesses across the industrial, transportation and logistics, technology and many other sectors. That experience helps when we come to work with you: we can help you get your product up and running faster, or build something extremely robust and secure. When it makes sense to lean on existing tools and libraries to build more rapidly, we can advise. And when it’s time to code from scratch for perfect fit between your business and your software, we can develop and design the perfect software for you.
We’ve helped businesses address their existing technical debt by replacing their software completely, introducing new tools, or working on the systems they already have. If you’re aware of your technical debt but not sure of its extent, or you’re uncertain of how to proceed, we can audit your existing software, assess technical debt and consult with you on how best to proceed.
Takeaways
- Most organizations are carrying some degree of technical debt
- Technical debt involves both degraded performance and risk, including outages and security vulnerabilities
- Technical debt can be mitigated, ‘paid off’ by replacing or rebuilding software, and largely prevented in the first place by choosing scalable software options with high-quality code that match your business processes and plans
- The best way to address technical debt is to work with a trusted partner that understands both software development and business, so they can advise you on what to do and why as well as on how to do it
