So what is Technical Debt? Who you ask will likely influence the answer that you get. Different perspectives will emphasise different aspects of the definition of “Technical Debt”.
In this article, we dive into what is meant by technical debt and why, on occasion, seemingly simple changes can take more time to implement than you’d typically expect. If you ask an average developer what technical debt is, you’d probably get the following explanation:
“Technical debt is where we’ve done something quickly, and before we build on what we’ve done, we need to fix up what we’ve done before.”
And it’s not uncommon for technical debt to rear its head in conversation like this — you may recognise similar conversations in your own experience:
“We need to address this bit of technical debt before we implement that feature that you’ve asked for.”
If we spend next week changing the way this part of the system works, we’ll be able to add new features to that area much quicker in future. If you ask someone else in a different area of the business (maybe in sales, marketing or operations) what technical debt is, you might get the following explanation:
“The developers always go on about “technical debt”, which slows down our ability to get features out the door!”
So who’s right — the developers or everyone else?
It’s not that simple — they’re both right (to an extent). Technical debt is a spectrum. On one extreme, you have a range of pros and cons, and on the other, a different range of pros and cons.
That’s why when it comes to technical debt, there is no blanket rule on what is right and what is wrong.
The context is important.
Let’s take a step back and define what technical debt is.
I’ve often seen technical debt described as “productivity drain” — unsurprisingly, that’s a more developer-oriented perspective.
However, the worst thing about this mindset is that it fails to recognise that accruing technical debt is more beneficial than not under certain circumstances.
“Technical Debt” is perfectly named, and the best analogy for this is debt in the financial world. Both financial and technical debt have a number of key things in common: Good Debt, Bad Debt and Interest.
Photo by Alice Pasqual on Unsplash
Bad Debt –
Bad debt is a bit of a blunt term, but in the financial world, this refers to everything that isn’t strictly Good Debt which we’ll cover later.
If we want to buy a car, we have two options:
- Wait until we have saved up enough money and buy the car
- Get a loan to buy the car, and pay the loan off over time
Under the first option, we’ll only ever pay the cost of the car, but we’ll sacrifice any benefits that could come from buying the car straight away.
Under the second option, we’ll end up paying more for the car — the cost of the car plus interest. However, whilst this will cost us more in the long run, we’ll only have to pay for the car in instalments, and we’ll be able to unlock the benefits of owning the car sooner rather than later.
Debt in technology is no different. At one end of the spectrum, you have:
- Wait until the feature is implemented in the way that we envisage before unlocking the benefits
- Implement the feature in a way that will allow us to start drawing down on the benefits more quickly
Let’s look at an example. Imagine you run a service that allows users to share photo albums online. You’ve identified that supporting video content in albums will be important for meeting the company’s review targets. So you speak to your development team, and they present you with two options:
We’ll need six months to implement this functionality, but when we launch it, it will have everything you need.
This feature is going to take us six months to build. But if we want to get it out this quarter, we can defer using a more scalable approach for storage. This means we can have the feature live in a month, but we’ll start running out of storage space after five months.
Like our financial example, the first option represents no debt, and the second option provides access to the benefit sooner but incurs debt.
In our second scenario, the feature is delivered more quickly, but debt is incurred because more work is needed to keep hold of the feature. We could skimp on our “repayment” of technical debt at the consequence that we hit the five-month mark and don’t have a solution ready for our storage issue.
Similarly, leveraging debt to build a feature may incur interest. In the long run, building the feature through debt could cost more, but this could be offset by leveraging revenue benefits sooner.
Good Debt –
Not all debt is bad.
In relative terms, houses are expensive. In most cultures, buying a house with a mortgage isn’t uncommon. We might give it a special name, but a mortgage is just debt, and usually a lot of it. Good debt isn’t frowned on in the same way as other debt and provided you stay on top of your repayments, a mortgage won’t stop you from taking out a loan for other means such as buying a new car.
Good debt only remains good debt for as long as repayments are being made. If we default on repaying our mortgage, good debt very quickly becomes seen as bad debt — the debt grows and interest spirals.
Technical debt is no different. You may incur technical debt, but if repayments are made at the right time, the debt can remain manageable and will provide the best possible trade-off.
Growing with Debt –
Let’s take a typical retail business that we’ll creatively call Retail Co. A new product is released onto the market that Retail Co believes will be a perfect fit for their customers. Everyone believes this product will outperform all other products Retail Co stocks. Retail Co is currently sitting on a healthy but modest £10,000 of profit. The new product has a minimum order of £18,000 worth of stock.
The business has two options:
- Grow organically — wait until they have enough cash reserves to buy the stock (they’re currently short by £8,000) Growing organically will take Retail Co some time. Retail Co will likely lose business to competitors during this time and miss out on substantial revenues.
- Leverage debt — get a loan and pay a bit more than face value for the stock (due to interest) but start selling straight away. Retail Co will be able to order stock more quickly and will be able to start selling to their customers. They’ll pay more for the stock in the long run due to interest, but they’re less likely to lose business to competition and potentially increase revenues sooner.
In a traditional business setting, both of these approaches if done responsibly are entirely acceptable approaches.
Technology is no different. If done responsibly, both organic growth and leveraging debt are perfectly acceptable ways to grow a technology offering.
Dealing with challenges of technical debt –
Technical debt, like most financial debt needs to be sensibly managed to avoid unexpected challenges;
We seem to have a lot of Debt?
If you go to a bank for a loan, the bank decides if the risk is acceptable or not. If it’s acceptable, you get the loan; if it’s not, you don’t. As the borrower, you can’t influence the lender’s decision. You might try to go elsewhere if you get declined, but you cannot influence the decision.
In a business with a technical team, if the management team keeps asking for features in a way that incurs technical debt, the tech team may get to a point where they decline to take on more risk. But the company’s management team can ultimately tell the tech team to build the feature, even if it goes against the level of risk that the tech team is comfortable with.
We can never get anything done because of technical debt!?
If a bank is averse to risk and turns down sensible risks, they’ll leave opportunity on the table. The same is true of technical teams with technical debt. A technical team unwilling to compromise will leave opportunities on the table.
These two challenges represent the two extremes. Like with most things, extremes in technical debt are undesirable but often arise where one party has overused their influence.
Conclusion –
Technical debt is often viewed as a negative, but if it is managed responsibly, technical debt can be used to maximise the opportunity of a product offering and leverage growth.
In our experience, the teams that manage technical debt have the best communication and collaboration between technical and product stakeholders. Maintaining a healthy balance sheet of technical debt requires collaboration, compromise and respect from both sides of the business — from the technical end and the product end. When this is done properly, we find that teams often coach each other towards the outcome which is best for the overall business at that point in time.