Technical debt is one of those phrases that has crept into the business vocabular of recent years, yet still it is not truly understood as to what it really means. In this piece I am going to highlight what it is, why it isn’t necessarily bad (at first) and why you should always look to pay it down as soon as you get a chance.

To help illustrate this concept I am going to draw upon a recent real-world technical debt, that I had to pay back.

The problem that needed solving was to create access across a small burn (it’s what we call a stream in Scotland) for our ATV to get over. The bridge would allow us access to an area of the woods that was inaccessible otherwise. It was a 10ft gap.

The quick fix was to use what we had at hand. As part of my frugal nature, I collect old pallets off of Craigslist, to use as burning material for our Solo fire pit. It just so happened I had a couple of 12ft pallets in stock ready for cutting up and burning.

Repurposing those, I strengthened them a little, and used them as the basis of our bridge. It was not going to be pretty, but it would allow the ATV to get over the 10ft span it needed to in a very short space of time.

Roping in help from my first born (now a fellow purveyor of the dark art of software development), we set about installing our creation.

Knowing this was not built using top-grade materials, we made extra provisions for strengthening the mid-way point, with struts that would take the weight.

The finished article, while not pretty, did the job admirably. The initial QA (“bounce up and down“) proved adequate and after the first successful drive over with the ATV with trailer, we claimed success.

No matter how well it worked on the day, deep down, we knew shortcuts had been taken. This was not an engineered solution by any stretch. We had cobbled together the materials we had at hand to create a solution that would allow us to solve the problem.

For the whole season, the bridge functioned without fail or concern. It performed well beyond initial expectations – had we stumbled onto a long term solution ?

No! We had bought ourselves a short term fix and incurred technical debt in the process. Fooling ourselves into thinking otherwise was going to end in tragedy. We had spent literally $0 in our bridge (except only our time) and by all accounts it was holding up.

We’ve all been there – the bridge is working and the business is getting benefit from it. So why do we need to spend or budget for a replacement? Next problem please.

Fast forward a year.

The first signs that things weren’t well, was when the first trip of the season, a number of the slats crumpled under the weight of the ATV. The bridge was in a sorry state of affairs.

The bridge had served its first season, but after weathering a winter it had gone out with its safe operating parameters. Decision time: do we go with another short term fix, replace the slats, or take this opportunity to design the proper solution, knowing what we know, to create something that will last?

Knowing my Scottish roots you would be forgiven for thinking I would have opted for the replacing of the slats and eeking out another season from the bridge.

No – research was performed, people consulted, a design created, and with a spreadsheet of materials, the new bridge was constructed.

Designing the bridge from the start for the ATV meant we could get the exact measurements and build something fit for purpose while looking the part.

Learning from Bridge 1.0, it was known that the wood having direct contact with the ground, would accelerate the rot. Using this information, we placed the new bridge on concrete blocks. Just because 1.0 didn’t last long, doesn’t mean there wasn’t learnings to be gleamed.

After a weekend of construction, Bridge 2.0 was ready for launch. I can proudly say it passed the QA with flying colours. Not a single rattle or movement – we had a solution that would, all being well, see us through for the next 10 to 15 years.

This evolution illustrates what it is like to incurr technical debt. Our initial bridge, was a short-term fix to get us through the immediate season. Using the materials to hand, we created a solution that would get us what we needed quickly and provide us with the learning that would determine if a more long term solution was required.

What if the bridge wasn’t used that much? That would have told us access to this area was not critical and we could have sought different (cheaper) solutions. Fortunately it was used, and each time, a little more learning was banked. We knew the position of the bridge needed adjusting, otherwise we would have had to fell some trees. We also learned how the bridge weathered through the winter with ice and snow. All in all, v1.0 gave us a lot to go into the design and build of v2.0.

Technical debt in the software world happens in the same manner. Fixing/resolving an immediate problem, keeping an eye on it, to see if it warrants further investment for a more scalable longterm solution.

As a software leader, be it CTO, VP of Engineering, Senior Lead, it is up to you realize when technical debt is being incurred at the time and keeping an eye on it as it ages and matures.

Create the time to pay back technical debt before something catastrophic happens (an ATV plunging “Back to the Future” style to the bottom of Clayton Ravine for example).

Alan’s must-read page-turner of a book “Think like a CTO” is available now.