Toxic Technical Debt

There is some debate going on over what exactly technical debt means 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. However, I do sympathize in that the debt analogy still makes sense. Nevertheless, 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.

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. 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. However, you want to get this customer up and running before losing them to your competition.

As a team, you might decide to take on some small technical debt to service your new customer faster. Instead of adding new features, you could create another instance of the application with a different configuration and slightly modified default theme. The key here is that you want to build this feature into the main application and get 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, one should always consider the risk of taking on debt carefully.