Technical debt is one of those things that every developer knew about before it had a proper name, but after Ward Cunningham coined the term we had a tool to drive conversation and encourage decision makers to do the right thing. It also gave us the ability to evaluate how much technical debt was acceptable and even sometimes necessary.
In the real world, completely avoiding technical debt isn’t feasible, but keeping it as low as possible is. Chris Hartjes wants you to also consider what he calls infrastructure debt:
Infrastructure debt is debt that you build up because you have not been paying attention to the process of creating the environments your application will exist in and have not been paying attention to the process of how your code gets from development into production. In my opinion, infrastructure debt is much more difficult to “pay off” than technical debt. Why? It is often very difficult for people to understand that it even exists.
It’s easy to see that there are all sorts of ways to accumulate debt while writing software. I’ve seen over and over again how stakeholders create debt in their products, seemingly without even realizing it, and without any help from the development team. That sort of debt is very hard for developers to pay back.
It’s not impossible though and with more examples of how debt builds and how to pay it down developers can educate themselves and the stakeholders.