Technical Debt

the good, the bad, and the ugly

Technical debt is an abstract way of talking about imperfections in a code base.

Similar to financial debt, there’s good and bad tech debt. That payday loan at 2000% interest? Avoid it. The mortgage which lets you put a roof over your family’s heads? Embrace it.

It seems like it should be easy enough to wrap your head around, but when it comes to tech debt people often get things backwards.

Tech debt decision makers generally fall into one of two categories:

  1. A manager of a large-ish project who doesn’t consider fixing tech debt to be a good use of resources.
  2. A developer who’s worked under (1) but is now starting their own project. They’re terrified of tech debt.

When to avoid tech debt

I still get flashbacks to the time it took two weeks to commit a single line code change to a codebase. This thing was a complex, ancient codebase with no sort of enforced programming standard. Reading through the code was like wading through knee-high mud.

There were automated tests, but they sat in a queue for an arbitrary time before running. The tests were non-deterministic - if they failed the generally accepted solution was to run them again (and wait another few days for the results). It’s impossible to be productive in an environment like this!

Large and long-running projects need a concentrated effort to counter the build-up of tech debt in order to maintain developer efficiency.

One trick is to encourage your team to tidy up tech debt when them come across it as part of their day-to-day development work.

But individual action is often not enough for projects of any serious scale. You need to talk to your team and find out where their work is being slowed down. Block out some dedicated time to tackling your tech debt so your team can move quickly again.

If you don’t, your project is going to burn through money without going anywhere.

When to embrace tech debt

You’ve worked on a project riddled with tech debt in the past. You know that when you’re running your own project, you’re going to do things the right way.

Architecture diagrams, full testing, full documentation. You labour over function names, variable names, and code structure.

If you know in advance what you’re building is going to have great product-market fit and meet the needs of your users (hint: if you’re innovating, you don’t) then go right ahead.

You’ll be better off if you can quickly explore new ideas. Try things out, fail fast, and iterate. You’ll zone in on the best solution with far less effort.

It’s pointless investing a mountain of time and resources into developing a bulletproof application when you’re not even sure it’s going to be viable.

Slow down the inevitable

Technical debt is going to build up in some form over time. But you can slow it down.

Some quick wins which you should absolutely be using:

  • Automatic code formatting
  • Automatic testing
  • Peer review for code changes

Summary & Further Reading

Not all tech debt is bad: it’s usually more important to develop software to meet a use-case instead of working about the 100% perfect solution.

But over time, tech debt can build up to the point that even small new features take far longer to implement than they should. This is when bad tech debt needs to be removed.

Using a few basic best practices will massively slow the build-up of tech debt in your projects.

For any particularly curious readers, Martin Fowler wrote a brilliant article explaining the concept in more detail.

Daniel Tipping

Daniel Tipping