Messy Code is not Technical Debt
docondev.blogspot.com
docondev.blogspot.com
To me, the difference that Norton makes out between "technical debt" and "messes" is at most one of degrees and in no way fundamental.
Messy code is difficult to maintain. You are incurring a penalty whenever someone needs to go in and make changes, a situation that is made all the worse when it is someone new. Perhaps my narrow programmer's mind can't appreciate the difference, but it sounds like technical debt to me.
It's more like there's two kinds of (technical) debt, one kind that you take on with a solid plan to pay it back later and the other kind, e.g. most credit card debt or programming messes, where you're just getting yourself into trouble with no plan for getting back out or realisation of how much interest you're going to accrue.
Yes you shouldn't do the latter, but it's still (technical) debt and the phrase is a handy tool for explaining why you shouldn't do these things to less technical folks.
Messy code may be called something like "Junk Code" (the metaphor being high-interest, high-risk junk bonds) or, if you're talking about code you didn't write yourself: "toxic assets."
In other words, it is a necessary term.
I have found this useful to keep in mind as I step a bit into the business world. For instance, "solution" and "value proposition" both mean something very important; the fact that many people sling these words around with wild abandon doesn't excuse you from needing to know what they mean. It's the same with "technical debt" and even things like "use case".
I side much more with 37signals (I think it was), who said any code you write will eventually become legacy code. Therefore I wonder if it is really worth fussing so much about the technical debt stuff. On the contrary I have more than once in my dark past as a Java programmer tried to do things "the right way", only to find that a couple of months later "the right way" was just as outdated as everything else.
So we all agree messy code == toxic assets? :-)
You did something, the customer is happy, but now you have to do something more because the first time you didn't do enough.
This author says wait! It's not because you made a mistake, hacked up your code, or changed done. That's some other thing, but not technical debt. Technical debt is when your understanding of the domain evolves and you have to refactor.
So who cares? From the customer's standpoint it's more stuff you have to do. Stuff that doesn't involve getting useful work done (in their eyes)
I believe he made his point, but I don't understand what kind of difference it's supposed to make. What? Are we supposed to invent yet more terms for messy code or redefinitions of acceptance criteria?
I agree in that you should not justify messes by calling them "technical debt" that you'll pay back later when in fact there is no pressing reason not to do it right other than your own laziness. But then, that's also true for the design variety of technical debt.
Yes, I do endeavor not to make them in the first place but even after years of experience nobody can completely avoid them.
You can choose languages and platforms that match the problem domain to the point of minimizing this, but it never goes away. And the longer code sits, the more "cruft" builds up on it. Once again, you can minimize this, but it never goes away.
I think once you learn good coding practices and start groking how easy that makes things, you start getting this bad attitude towards everybody else. Those other stupid programmers, you think, If they were only as smart as I am most of these problems would go away.
Later on you figure out that some of these guys are actually smarter than you, read all the books, could do and teach this stuff in their sleep, and know that their code needs work. At that point you're just beginning to become a true professional.
Ok, I'll buy that. But to me, from an external point of view, my developers have all this extra work to do which doesn't have to do with their backlog. So who cares what the term they use is?
I think he's just mad at sloppy coders co-opting a favorite term. I see so much muddled language it doesn't really bother me. As one other poster noted, it's not like when you coin a term you get to define what the term means for the lifetime of the universe.
I've always understood it as just the opposite: the circumstances don't permit doing it right, so you do it badly knowing it'll cause problems, and the costs grow the longer you leave it unresolved. Debt is a metaphor for choosing to sacrifice your future self's resources, not just making mistaeks (even if they have the same result).
But if I understand this author correctly, that's not what the term originally meant.
There certainly is value in refactoring poorly written code and I would love a metaphor that described that. As it is talked about in this blog post or by Ward I'm not sure I care at all about tech debt as a factor in software development - it seems like an interesting idea, but at best a minor productivity boost when compared to removing messy code.
It seems we need to recognize that even with our best efforts we eventually crack and write something poorly. While it is painful to recognize this openly, it seems necessary in order for us to come up with ways to deal with it. We need to know why we end up writing such code, how and when to remove it, and how to sell our customers on the value of removing it without losing their trust and looking unprofessional.
If you don't know how to avoid it, then calling it "natural" allows yourself off the hook from getting any better.