If you watch daytime TV in the UK, Then you might have seen Can’t pay? we’ll take it away or Can’t pay? as it’s affectionately known by it’s fans.

Can’t Pay? follows a group of High Court Enforcement Officers (Called sheriffs in the states) as they enforce High Court writs — judgements by the High Court that one person owes some other person money.

As the shows title so elegantly puts it — If you can’t pay we’ll take it away — In other words if you don’t pay the money that the High Court demands of you then the agents can remove goods of a value high enough to cover the debt.

A key learning from ‘Can’t Pay?’.

One of the issues that Can’t Pay? addresses is the debt trap. This trap starts when a person gets into a (relatively) small amount of debt. On top of that debt they have to pay interest. If they struggle to pay the debt + interest back then they end up having to pay court fees, agents fees and more . Before the they know it the total amount requested is massive.

Our code is like our debt.

Photo by Artem Bali on Unsplash

It was Ward Cunningham who first came up with the ‘Technical Debt’ metaphor.

To explain it I’ll bring back someone from my first ever blog: Frank. Frank’s code has some shall we say — interesting — Quirks which he wrote when racing to beat a deadline. Writing these quirks is like going into debt.

After the deadline has passed, Frank has to go back and fix what he did. This is like repaying the debt.

In between the code being changed and Frank going back to fix it, the bad code had become further ingrained in the system. This is as a result of subsequent changes on top of the bad code. Equally Frank has forgotten how his poorly written code works and now has to relearn it. This means that fixing the code later takes longer than writing it properly the first time would have. This is like repaying the debt with interest.

There is a software debt trap.

Much like in real life your code can fall into a debt trap — A point where the total sum needed to repay is far greater than the original amount of time you saved by rushing out your code. You’ll know you’ve fallen into a debt trap because:

Developers can no longer trust themselves to change the code without breaking it.

The top talent demands to be moved to other projects.

Seemingly simple changes take weeks, even months.

Imagine trying to save a piece of software in these circumstances? Is that really a project that you would like to work on?

How to avoid a visit from the digital sheriffs.

Photo by Tom Kulczycki on Unsplash

The majority of the time technical debt is down to deadlines. Realise that 95% of those deadlines are arbitrary. As developers we don’t have the power to set those deadlines but we do have the power to set expectations.

It’s hard and controversial to admit but 90% of ‘out of touch’ managers are backed up by ‘nodding dog’ developers. If you don’t think that the code can be done in time say so. Often you’ll find that managers will only need a subset of the features that are requested by the deadline and thus an achievable package can be negotiated.

If the deadline really can’t be moved, make it clear to management that a hack is required. Explain the technical debt metaphor and put a card in the backlog to fix your mess.

The worst possible thing you can do is write a hack and forget about it. or worse still write more hacks on top. If you do that it won’t be long before your code falls into a debt trap.