Technical Debt is Not a Bad Thing

If you work around developers, you have probably heard the term “technical debt.” It’s a widely used metaphor that is useful when considering how to build and maintain software. The term was coined by Ward Cunningham, a computer scientist who created the idea of a wiki and contributed heavily to the development of object-oriented design patterns.

But even though the metaphor is widely used in the world of software development, I meet a lot of people who don’t understand what technical debt is and why it matters, or people who are completely unfamiliar with the term.

What Is Technical Debt?

Our understanding of a software problem evolves over time, and our code should reflect our current understanding of the problem. We accrue technical debt and borrow money as the gap between our current level of understanding and the level of understanding reflected by the code grows. When we gain experience and understand more subtleties and nuances of the problem, we refactor our existing code to match the latest model. We use that experience to pay down the principle that we borrowed when we released code that we knew was not going to reflect a changing reality.

If we fail to perform this refactoring, we are paying interest on the debt every time we interact with the code; synthesizing the two disparate models of understanding increases cognitive overhead, leads to communications problems, and makes it harder to choose tooling that is optimized for the problems we currently face.

What Technical Debt Isn’t

It’s important to be clear that writing bad code is very different from acquiring technical debt. If you can’t refactor your software because it is poorly architected or poorly written, you don’t have technical debt, you have bad software. As Ward says himself in the video embedded below: “The ability to pay back debt…depends upon you writing code that is clean enough for you to refactor as you come to understand your problem.”

And it’s easy to fall victim to the thinking that debt is always a bad thing, but that’s not always the case. Debts are a trade-off, and smart borrowers understand that the long term benefits often outweigh the costs–a college degree can help a person earn enough money that going into debt to get one can make sense. Similarly, technical debt is something that developers should knowingly take on in order to improve their product in the long term. When he was originally describing the metaphor to his boss, Ward says “I thought borrowing money was a good idea. I thought rushing software out the door to get some experience with it was a good idea.”

Tech Debt in its Natural Habitat

If you’re in the startup world or have read books like The Lean Startup, then you are already familiar with this idea. Build a prototype, gather feedback, and iterate. The “minimum” in “minimum viable product” represents technical debt: at some point, if your prototype proves your hypothesis, you’ll need to build out the rest of the product according to what you’ve learned from your potential customers. Not only is technical debt a positive thing for startups looking for product/market fit, accruing that debt in order to test things is a proven strategy. After all, there’s no penalty if you default on the loan, other than the minimized time spent developing and testing the prototype.

When you don’t pay down technical debt, just like real debt, it becomes a big problem, as I explained in Dirty Socks and Technical Debt.