About a year ago I stumbled upon an old video by Ward Cunningham, one of the original Agile fathers, about technical debt.

There he described debt as the natural result of writing code about something we don't have a proper understanding of.

If we fail to make the program aligned with what we understand to be the proper way to think about our [...] objects, then we are going to continuously stumble into disagreement, and that would slow us down like paying interest on a loan.

The video and the quote above inspired me to write a full article about the elusive meaning of technical debt, which as of today is still my most popular article ever, with more than 50,000 views.

The article focused on what technical debt really is and how you can prevent it in various scenarios. It did little, though, to help you address and reduce debt once it’s there.

This new article is a practical, thorough guide to managing technical debt with your team, from the quarterly strategy down to the day-by-day.

It covers:

• 🔥 The impact of technical debt on your team

• 📈 How debt changes with product maturity

• 🏃‍♂️ How to address it: small vs medium vs large debt

• ⚖️ How to assess technical debt

As always, the article takes from my own experience, plenty of readings, and conversations with the best engineers I know.

Most of all, it is a joint effort with folks from the Refactoring community, who have been invaluable in sharing real-world processes and examples (shout-outs inside the article). You can find here a sneak peek of the main thread.

Let’s dive in 👇