Simply Business homepage
  • Business insurance

    • Business Insurance FAQs

    Business insurance covers

  • Support
  • Claims
  • Sign In
Call Us0333 0146 683
Chat With UsChat support 24/7
Tech blog

A Debate on Tech Debt

3-minute read

Simply business

Simply business

5 February 2016

Share on FacebookShare on TwitterShare on LinkedIn

Gleaned shamelessly from a Slack chat: musings on the concept of technical debt

Alessandro Morandi

I found the analysis in that article very interesting. Technical debt has become such an all-encompassing term, it’s useful to be reminded of what it actually means.

Lukas Oberhuber

Kellan Elliott-McCrea argues that only a very small portion of what he lists is actually technical debt. I disagree -- I think he's excluding too much.

I do agree however that "2. Features of the codebase that resist change," is an area that is not tech debt. No one can build a system that can handle all changes, or even predict them, so the fact that some of them may be hard to do should not qualify as tech debt.

I think splitting debt into many categories is absolutely fine, but the cost of changing the codebase/system is real. Technical Debt (in my head) is all about the difficulty of making changes. The fixes are many and need to be understood to be successful. I strongly believe you can pay off Technical Debt, but you’ll never pay it all off.

But systems with less tech debt last longer and can scale to more functionality (see reference here.

Here are two videos of my talk on the subject: technical bankruptcy at APM, and technical bankruptcy at CukeUp 2015 (registration may be required). Or just the slides here


That article resonated with a couple of thoughts about Tech Debt I was considering recently. To me, Tech Debt is often portrayed as the consequence of something that was ​done wrong​.

I think of it more as an inevitable consequence of time. A bit like wear and tear, there’s no way of avoiding it. You can build a system that’s more resilient, but eventually you’ll have to address some issues because that’s how artefacts work in this world.

(I’m not saying that’s your view by the way ;-) )


I think complexity is inevitable and causes some problems, time is inevitable and means that change is needed, but tech debt is inevitable because we usually have delivery deadlines.

However, you can also pay it down again. Kellan Elliott-McCrea is talking about some things that happen not because they are done wrong, but that they no longer apply. I agree those aren’t tech debt, unless you fail to make the change when it is needed. When that happens you instantly get a huge pile of tech debt.


One consequence of the way of thinking about Tech Debt I outlined above is that you need a two-pronged approach: on one hand you can try to prevent it by building a resilient system; on the other hand, you have to constantly pay it off to avoid the system decaying, no matter how good it was in the beginning.


Maintenance is a must, and failure to do it turns into tech debt. Doing it is avoiding that debt, so I think we are in agreement.


Yeah, it’s semantics now :)

I think you’re calling it Debt once it becomes a sore spot, while I tend to extend that to the constant wear and tear.


So when we change Insurer into Provider [ed- a domain model change we did recently], that’s not tech debt. That change is a consequence of needing to change. If we then decide to do it only on half our systems, that's debt. Leaving it as is in so many places means that now everyone needs to understand that the two things are the same most of the time, but not always. That’s tech debt.

Doing it at the right time, 'wear and tear' is preventative maintenance.

Simply Business Tech leaders


Yeah, I see what you mean.


Potholes are an inevitable consequence of winter, however not fixing them over time turns a safe road into a road that causes accidents which is then debt (not tech, but debt nonetheless).


I would have said that changing Insurer into Provider is ​paying off​ tech debt, which we have accrued when time changed our situation.


Think of the London Tube. All those signal failures are debt. [ed- these happen way too much]

Changing Insurer to Provider is a new feature as we change the domain model of our business. Doing it at that time avoids the debt of not doing it.

But yes, semantics. Like not having to take a loan since you didn’t need the money in the first place.


Yes :)


Typically paying off your bills in time is not considered debt :)


Yeah, in that sense it’s only debt when you’re accruing interest.

And I remember a similar concept in your presentation.

So in a sense tech debt generates more debt the longer it's in the system. Changing requirements don't.

I still wish we had a better term for when you have to do work because the domain has changed - or your knowledge of the domain has changed. "Tech Debt" is a pretty neat shorthand and I'm not surprised it's (mis)used everywhere.

Ready to start your career at Simply Business?

Want to know more about what it's like to work in tech at Simply Business? Read about our approach to tech, then check out our current vacancies.

Find out more

We create this content for general information purposes and it should not be taken as advice. Always take professional advice. Read our full disclaimer

Find this article useful? Spread the word.

Share on Facebook
Share on Twitter
Share on LinkedIn

Keep up to date with Simply Business. Subscribe to our monthly newsletter and follow us on social media.

Subscribe to our newsletter


Public liability insuranceBusiness insuranceProfessional indemnity insuranceEmployers’ liability insuranceLandlord insuranceTradesman insuranceSelf-employed insuranceRestaurant insuranceVan insuranceInsurers


6th Floor99 Gresham StreetLondonEC2V 7NG

Northampton 900900 Pavilion DriveNorthamptonNN4 7RG

© Copyright 2024 Simply Business. All Rights Reserved. Simply Business is a trading name of Xbridge Limited which is authorised and regulated by the Financial Conduct Authority (Financial Services Registration No: 313348). Xbridge Limited (No: 3967717) has its registered office at 6th Floor, 99 Gresham Street, London, EC2V 7NG.