Technical Debt
Hero Section Background

What Is Technical Debt?

Matt Campbell | Web Development

In the world of web and coding, you will hear the term technical debt banded around a lot. It’s one of those terms that you’d be forgiven for thinking is just something web developers use to sound knowledgeable. What does it actually mean? What is technical debt?

In this article we explore exactly that and hope to answer some frequently asked question surrounding the term technical debt.

A quick Google search for “What Is Technical Debt?” returns a bazillion results. Alright, maybe not that many – but it’s a lot. Let’s break it down.

Technical Debt Definition

Wikipedia has a very nice definition.

Technical debt (also known as design debt or code debt) is a concept in software development that reflects the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.


So, let’s apply that to building a website and in particular – building a WordPress website.

In short, technical debt is when a decision today, leads to additional work in the future. It is when work is required to undo or correct previous development. Development that was done in a manner without thought or consideration for future growth.

Basically, it’s taking the quick and easy option. Often, cheaper priced but more costly in the long run.

What’s The Impact?

As with any kind of debt, the only way to get rid of it is with time and money. And yes, there are interest payments to make.

Let’s run this scenario. You’ve got a site and you wanted to add a blog. It’s built quickly and cheaply, incurring technical debt as a result. An example might be a feature to allow users to favourite articles or add them to a reading list.

The feature is built but the way the saved posts are stored doesn’t scale due to every post in the database being checked against the saved posts list. It works if the site has a few hundred posts but as the blog grows, the check becomes slower and slower.

Now, you’d like to add some new features to the blog. For argument’s sake, we’ll say it’s $1,000 of work. But, upon investigation the developers discover the poorly conceived saved posts feature.

Realising the cost of the technical debt

The developers report back that there are two options available:

  • Add to the current system.
  • Rebuild the whole thing from the ground up.

Adding to the system is a terrible idea. While it’s the quicker and cheaper option, it still has a higher price and all it does is get you further into debt. On this occasion, it might cost $1,200. That $200 is the interest you’re paying on your technical debt. The issue here is, next time you want to $1,000 of work on the blog, the price might be $1,800. You never actually pay off the capital of the debt. Furthermore, the whole system becomes more unreliable with each development round.

You might think, why would anyone ever consider the first option? Well, money. Can you afford to clear the technical debt because that’s what option 2 is all about. To pay off the debt, you must first rebuild the blog from the ground up and then pay for the new features. As you can see, the cost of the blog has ballooned. You end up paying for the same thing twice. However, you are then clear of any technical debt.

Avoiding Technical Debt

It’s actually very easy to avoid ever going into technical debt. All it requires is a little foresight and planning. The bulk of the responsibility for this falls to the developers. They should be asking questions about future plans and the site’s growth. More importantly, they should be building sites in a manner where they are easily maintained and extended.

Sadly, many times a site is built with this sort of technical debt at its core. The developers can lack the expertise to build an extendable site that scales or are simply more interested in getting paid as quickly as possible. As such, they just see the job in front of them and build for that and that alone. They don’t think about or care about future development and how today’s work, might impact tomorrow’s.

Such an attitude results in massive technical debt. We’ve seen it before when a developer ignores the rest of the code base and adds unnecessary code because it’s quicker and easier than understanding the existing architecture.

Good project management and developers with business sense are critical to avoiding technical debt. As such, it is important to pick a development team that takes an interest in your success beyond the job they’re being hired to complete.

Common Causes

  • Lack of or poorly defined project scope – requirements are still being defined during development, development starts before any design work takes place. This is done to save time but often means elements of the project are reworked later on. This ultimately incurs more financial investment.
  • Time constraints – the business considers getting something released quickly. This causes elements to be less planned and organised than normal as things are rushed.
  • Lack of understanding – businesses make decisions without considering the implications. It’s down to the development team to act as a check here, asking the difficult questions. Often, price is the driving force behind a decision which ultimately will cost more as time passes.
  • Poorly organised functionality – the code can’t be easily extended which means code is duplicated or rewritten as the site grows.
  • Quick fixes – risky band-aids to fix bugs.
  • Documentation – code is created without necessary supporting documentation. The work to create any supporting documentation represents a debt that must be paid. 
  • Simultaneous development – accrues technical debt because of the work required to merge the changes into a single source base. The more changes that are done in isolation, the more debt is accrued through duplication of functionality.
  • Delayed refactoring – as the requirements for a project evolve, it may become clear that parts of the code have become inefficient or difficult to edit and must be refactored in order to support future requirements. The longer that refactoring is delayed, and the more code is added, the bigger the debt.
  • Ignoring coding best practices and standards – where WordPress standards are ignored. This ultimately leads to rewriting of code to bring it inline with best practices.
  • Lack of knowledge – the developer simply doesn’t know how to write elegant code.
  • Technological leadership – instructions from the lead developers compromise the code base. Developers implement code because they’re told to without consideration to the overall project.
  • Last minute changes – these have potential to infect a project. Lack of time or budget means they’re not properly considered prior to implementation.

Get In Touch

Please submit your query & a consultant will get back to you.

Please make sure all required fields are completed.



Thanks for your message

A consultant will contact you shortly!

or call 01905 570735

Related Articles

A busy press conference
06 Apr 2020

From the CEO: Announcing our C-19 Response Package

When the government announced it was closing the high-street I, GloboTek CEO Matt Campbell, started to think about what we […]

Move your business online banner
26 Mar 2020

Reacting to COVID-19: Move your business online

Literally overnight, the retail industry in the UK has been forced to close. With traditional bricks & mortar stores no […]

Discussion over a pie chart
16 Aug 2019

Digital Marketing for Zoos White Paper

Today, we would like to announce we are producing a white paper on Digital Marketing for Zoos. Our objective is […]