Toxic Technical Debt

There is some debate going on over what exactly technical debt means in relation to a software project. The main issues seem to be what makes up technical debt and whether it should ever be acceptable to take it on.

Dirty Code Is Not Technical Debt

I do not believe authoring dirty code or code without corresponding tests should be considered technical debt at all, but I do sympathize in that the debt analogy still makes sense. However, this is not the type of debt one should ever want to take on in a project. There is never a valid reason for authoring production code without tests.

Toxic Technical Debt

I consider this form of technical debt to be toxic technical debt. That is the debt analogy applies but the risk is not ever worth taking and eventually it can bankrupt your organization, quite literally.

Real Technical Debt Can Be Beneficial

I do agree that technical debt is perfectly acceptable to take on for valid business reasons as long as you pay that debt back responsibly, by making a large or complete payment on the principle starting in the very next iteration. Paying only the minimum balance will get you into big trouble, just like in real life.

A simple real world example would be if you had a software service that served multiple customers from a single installation. Let’s now say that you acquire a new customer and the first thing they want is to be able to run the application on their own domain with a slightly modified theme. The problem is that your app is in an early stage of evolution and doesn’t yet support such features, though you do want to get this customer up and running before you lose them to your competition.

As a team you might decide to take on some small technical debt in order to service your new customer faster. Instead of adding new features you could just create another instance of the application with a different configuration and slightly modified default theme. The key here is that you want do it with intention of building this feature into the main application and getting rid of the separate instance once you have the customer up and running. Not doing so would be considered paying only the interest on the debt, something you want to avoid at all costs.

Even though technical debt can be beneficial, the risk of taking it on should always be considered carefully.


Hi there, I'm Seth Deckard, a software developer with years of experience working in Ruby and Rails. I co-founded WarningAware and have authored several open source projects on GitHub. You can reach me on Twitter.