Website technical debt

Many years ago, when I was at Uni, I bought a cheap 8v Golf GTi. It was my pride and joy and, at first it was washed every weekend and I fixed every little niggle fixed on my parent’s driveway. However, being young, having little money, and spending what I did have on beer, I started to put off fixing minor issues. One by one they piled up until one bit squeaked, another bit knocked, other bits were tired, and didn’t work. Over time the car deteriorated until one day, with the engine sounding like a bag of nails, it failed an MOT, and was not cost effective to repair. Time to sell it as ‘spares or repair’ and cut my losses.

What happened is my car built up technical debt... i.e. I was in debt to the car, not with money, but with repairs and maintenance.

This happens all the time with websites and larger web-based systems. Unlike a car, they do not wear out, but they do need regular love and attention to keep up to par.

Their needs can be overlooked as websites do not clunk and bang, and why would someone want to spend money on something that functions perfectly? With a car, the product itself deteriorates. With a web-based product, although the code itself may not change, everything around it does. The infrastructure that runs them, the devices and systems that read them, the systems that they communicate with, and the users that use them, all get upgraded meaning that the website is left behind.

This could be something obvious, a good example being when websites went from being solely desktop based, to ones that are mobile friendly; or could be something invisible such as out of date and out of support code bases. The latter is arguably worse as it can not only have serious consequences with security, but can remain undetected by the owner.

Putting off dealing with technical debt is not just delaying the cost, it actively grows it. Here’s why:

The bill compounds. With my Golf, a small tear in the CV joint rubber, which was a £12 gaiter (at the time) turned in to water ingress, and a replacement driveshaft needed. Code works the same way. A dependency that needed a minor update two years ago may now need a full architectural overhaul because everything else was built on top of it.

Other systems stop talking to it. Modern web systems integrate with payment providers, CRMs, and third-party APIs, to name a few. When those providers move on, an unmaintained system can lose critical functionality, sometimes overnight, without warning.

Workarounds eat your budget. Developers working with debt-laden code spend as much time navigating around old decisions as building new things. Each quick fix makes the next fix harder and more costly. This grows exponentially.

The knowledge disappears. With the multiple workarounds above, on larger systems, when the original web developers move on, and new developers looking at the problem are greeted with a “what the hell is going on?” moment. They need to decipher not only the issue, but why each workaround was implemented previously. This makes the project longer, and more expensive, as well as there being much higher risks of things going wrong. If you have a project where issues appear each time another one is fixed, this could be why.

The running cost lies to you. My Golf felt cheap to run right up until it wasn't. Older web systems can look affordable on paper, with modest hosting fees, and no obvious issues. This is all OK until framework hits its end of life, a host forces an upgrade, a security exploit surfaces or something stops working. That "cheap" system can suddenly need a huge remediation bill with very little notice.

All of this can happen without any obvious warning signs, the technical debt creeps up stealthily until one day a web developer has to inform the owner that their website is not fit for purpose, or even worse, beyond economical repair. This, of course, usually comes at the worse time. Quite often, even if budget isn’t the primary concern, timescales can be.

If your web-based product has been neglected, it will likely have technical debt. And although this is a problem that can be kicked down the road for a bit, it will need to be dealt with at some stage.

Our advice would be two-fold. Firstly, to keep on top of updates when practically possible, and secondly when the end of a web product is on the horizon, start putting money aside for a rebuild. Sometimes a combination of both with a quick patch and long-term plan of action. You’d use this strategy this with a car, or your garden fence, so why not a digital product?

So, how do you know where you stand?

Well, talk to us. We’re happy to either have a quick look and chat for free, or do a full audit.

We are Webbed Feet, we help clients manage technical debt to avoid nasty unexpected surprises.