Understanding 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.

We'll share some examples of technical debt that we've spotted in the wild, to help you identify it in your own codebase—before it catches you off-guard.

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.

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.

You know how it is. It’s already hard enough to squeeze everything you need into a sprint without trying to find an extra 10%–20% of engineering time to pay back technical debt. If you’ve ever argued for carving out time for this, you know that it can feel like a crusade of epic proportions.

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 hard part. For