Human communication is a funny thing. We use phrases like “technical debt is bad” and everyone in the room will nod their heads and be in total agreement, but e

Human communication is a funny thing. We use phrases like “technical debt is bad” and everyone in the room will nod their heads and be in total agreement, but every single person in that room has a different definition of what technical debt is. To some people it means “buggy code”. To others it means “not the way I would have written it”. Yet to others it means “code that is hard to understand”. What it means to me could be any one of those things, but the defining factor is that there is an ongoing ‘cost’ to the code in question. What kind of cost? Usually time-based cost. It takes someone’s time to manage and handle the situation. It could be that the code causes data inconsistencies that have to be managed by hand occasionally. It could be that frequently updated code takes 100 times as long to change as it should. It could be that the code has grown in complexity to the point that I can’t put a junior developer on it, requiring expensive personnel to maintain. It could be that it compromises the user experience, hampering user adoption. In all of these cases, the underlying is that it costs money. Like true debt does. Which is why using the term “debt” is a perfect description. I would argue that if a piece of code is clunky, buggy, or poorly written, but has no clear impact on the business in any way, is it truly technical debt? One might argue that the person making the decision to write it that way made a pretty valuable business decision. It is like a 0% loan. Until that loan starts costing you money, you would be a fool to spend time paying it off.