‘Tech debt refers to the off-balance-sheet accumulation of all the technology work a company needs to do in the future.’ McKinsey
You’ve probably heard of ‘tech debt’ and how it can impact a company. However, have you ever tried to explain it to non-technical colleagues in basic terms? It’s important to your company, and it’s essential that other functions in the company understand its impact and even its existence!
So, here’s a look at what technical debt is and how you can ensure your people understand the concept and how it works. After all, technical debt is more than a metaphor.
What is tech debt? A refresher
Programmer Ward Cunningham created the term in 1992, and it describes circumstances when software engineers and architects settle for software solutions and pay for them later (with interest!).
Often referred to as code debt, design debt or tech debt, technical debt describes the act of moving ahead with code and architecture to save time, but it will need fixing at a later stage.
So, while it can be faster and more efficient to neglect the need for writing perfect code, there will be consequences longer term. You’ll likely achieve the goal faster, but the intentional shortcut can leave you with less agile code and is harder to maintain in the long term.
Although some technical debt is inevitable because leadership pressure or project deadlines mean it cannot be avoided, it needs to be managed responsibly and not just ignored forever!
Is it similar to financial debt?
Not exactly, but referring to financial debt can help to explain tech debt. For example, you usually take out a financial loan because you need to pay for something urgently, so you borrow the money. Similarly, with technical debt, you may be sacrificing quality because you want to do something quickly. While this is great for speed, the design decisions you make will impact what needs to be addressed later on.
With financial debt, you’re left to pay off a debt, and if you don’t and you keep borrowing, it will spiral out of control. It’s not dissimilar to technical debt, as you have to update code at some point down the line.
CTO Craft community member Stephen Cox and CTO of Strivacity says, ‘Technical debt is like a mortgage. It’s okay to take on technical debt (things that you may need to fix or improve later) to shorten the time to be able to ship something. But, like a mortgage, you have to pay it off, each month, or you’ll get in trouble and be evicted. And you cannot take on too big of a mortgage.’
Why does technical debt occur?
In the reality of business goals, external competition, and pressured deadlines, sometimes engineering teams have to use new systems and processes to improve user experience, cost savings and move away from old tools. As a result, they will often have to review the trade-off between taking more time or going quickly and incurring some technical debt.
Ken Baxter, Interim CTO at Glean, believes that technical debt should be explained in ‘Plain English.’ He adds, ‘Software is built by humans. As good as they are, they will never be perfect, and they are battling between the desire to be close to perfect and the drive to get stuff to customers. So, there will always be areas that need some maintenance and improvement.’
Why does it matter?
If you get into financial debt, you’re going to have a backlog of bills that will continue to build up if you don’t pay some of them off. With technical debt, the same is similar in that your debt will build up until it becomes unsustainable. Then, while your team is spending their time repairing the issues, new work (potentially revenue-making work) will be neglected.
At Episource, Christophe Louvion, CTO, says, ‘Unmanaged tech debt is like gravity. The bigger the planet, the more gravity, the more energy to achieve the same distance of movement. Slower pace companies lose over faster companies. As such, CEOs should ask engineering to materialise tech debt friction and set boundaries to manage this major corporate risk.’
And there’s the broader impact on customer service and productivity. If you want to respond to your customers quickly and efficiently, you need to limit your technical debt, and if you have high technical debt, it can hinder productivity. For example, if you want to build a new feature, but debt is high, it can slow progress and make the task much harder.
Ken Baxter adds that regular tech debt reviews are essential, ‘Technology moves on, our customers have new requirements, our business grows, the domain we work in changes (security, compliance, cost of ownership of tech), and as a result, as we evolve, so must our technology. Tech debt is about doing nothing to remedy that.‘
‘We can either do that in a massive rewrite in years to come when the problems become massive and threaten us, or we can chip away at continuous improvements, a bit like David Brailsford/British Cycling and their incremental gains. Making small improvements regularly is more effective than trying to make big changes in one go.’
Technical debt is inevitable and is caused by technical decisions that aid speed, cost or simplicity but may increase risk or slow you down in the long term. To achieve a tight deadline, a small risk or a series of small risks can unknowingly accrue large technical debt. So, for best practice, you should regularly review, repair and clean up the technical debt, but in reality, it may not be quite so straightforward.
We will be digging deeper into this topic in future blogs to discuss ways to visualise, mitigate, plan for and pay down technical debt.
***
If you or your CTO / technology lead would benefit from any of the services offered by the CTO Craft community, use the Contact Us button at the top or email us and we’ll be in touch!
Subscribe to Tech Manager Weekly for a free weekly dose of tech culture, hiring, development, process and more!