Understanding Tech Debt 🧐

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.

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?

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