Addressing technical debt is rarely about making time for large fixes. It’s about setting strong examples for improving code in our daily work. It’s about celebrating the ability to refactor code to make it easier to work with.

I really like the approach the author takes in categorizing the various types of technical debt one might come across when building software.

The part that I found most enlightening was about yearly debt:

Yearly Debt is the kind where after lots of conversations, someone concludes a rewrite is the only solution. Sometimes a rewrite may be the only solution. Sometimes you may have a Ship of Theseus problem on your hands where you need to slowly and methodically replace parts until the system is the same but different.

Sometimes, though, this isn’t really debt. It’s possible that your dilemma is the result of growth or changing markets. In that respect, calling it debt does a disservice to our success, and distracts from solving the problem of growth.

Brilliant. The “debt” metaphor is apt because not all debt is created equally.

If your town grows into a city, you eventually need to take out debt to build out new infrastructure. You might need to add a few lanes to the main bridge that passes through town. You might need to add more parks or theatres or schools to attract more people.

This incurs debt, for sure, but the payoff comes down the road when you now have an attractive city with amenities that help keep the city vibrant and growing.

The same applies to building software. Sometimes, the algorithm that got you here won’t work for the new customer you want to attract. Sometimes, the frameworks you used to build your mobile app are no longer able to support the hot new feature you want to add.

When framed like that, you no longer call these projects “debt”… you call them investments.

Investments are different from the sort of debt you incur from re-landscaping your back yard for the third time in four years.

’But,’ you say, ‘premature optimisation is the root of all evil! Duplication is better than the wrong abstraction! Don’t be an architecture astronaut!’

The developers I’m thinking about already know of all those takes and have internalised them long ago. They know that sometimes ‘good enough’ is the right choice given the constraints of a project. They know that sometimes you need to cut scope to stay on-track. They know that sometimes it’s better to wait to learn more about a domain before rearchitecting a system. And yet in spite of those constraints their output remains golden. These are hard working motherf*ckers whose diligence and perseverance put other devs to shame.

Other devs… like me.

Sometimes, I just CBF.