Over the last six months, I’ve interviewed more than 200 top software engineers about tech debt. In this post—the first in a series which will crystallise my learnings from this experience— I'll share with you how the best in our field make the business case for any given piece of tech debt.

Most engineers have heard of the 'boyscout rule': 'Always leave the code better than you found it.' But if it's that simple, why isn't everyone doing it, to curb tech debt once and for all? You guessed it, it's not that simple. So let's figure out why—and what we can do about it.

In this article, we'll go through the meta-problems caused by tech debt, and discuss exactly how they affect each area of any software business. This will give you the tools to alleviate a lot of the pressure your engineers have to deal with.

There are plenty of ways to avoid the dreaded technical bankruptcy. To separate effective from ineffective solutions, we need to gain a deep understanding of the forces at play and their roots in sociology, criminology, and game theory.

Tech debt is just a thing that happens, right? We start writing code, tech debt accumulates, and bam, there's suddenly too much of it. But does it have to be like this? Are there some fundamental laws of software development that make it so? Can we bend these laws to our advantage?

Given our broader definition of tech debt, the only real solution is to continuously address the most pressing technical debt as we continue to deliver features at pace for our customers. That's the tech debt that we know for sure will slow us down today, or soon.

Today, we’re sharing with you some of the best, tried and tested, scientific methods to measure technical debt. You too will be able to get quantitative data to back up your intuitions about technical debt in your company’s codebase.

It’s easy to pay lip service to company culture. But few companies actively consider those few cultural characteristics that make a meaningful difference to performance—because that’s the