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.
I actually somewhat disagree with the premise of this article, but I found it quite thought-provoking. From my standpoint as a programmer, the concept of "messy code as technical debt" is too valuable as a tool to get my manager on board with rewriting & refactoring to get rid of. I would consider ceding "messy code" as part of my definition, but only if an equally expressive phrase were coined in its stead.
Well I think the underlying concept is that we need additional terminology to support multiple issues. Here, technical debt's the intentionally short-sighted design decisions written in such a way that it's easy to refactor (e.g. debt, but low interest).
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."
I think of it as a geeky buzzword invented by coders to get management to understand the need for refactoring, increasing test coverage, and other necessary "mess-cleanup" actions that revisit working code.
Behind almost every buzzword is a useful concept. "Technical debt" is not one of the exceptions.
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 am not disagreeing in principle, but I have a hard time seeing the value proposition of "technical debt". Doesn't it translate directly to "bad code will cost you in the end, therefore you should hire expensive consultants who know how to code"?
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.
There's a big difference between trying to do things "the right way" and finding out your code still became obsolete, and winging it to produce crappy, unmaintainable code that will cost you hours many times over!
I disagree in the situation where there is a business case for slinging something fast out there: sometimes it can, and certainly has for me, move the project forward in terms of money or some other short term goal. So be it, one can't fight gravity in certain situations (i.e., create time that simply doesn't exist). If your goal is to merely create great code then I guess that does not apply but I suspect few (working) people are actually in that situation.
So Technical Debt is natural and expected where messy code should be avoided. While this all may be true messy code has the same results as true technical debt. Get too much of it and your producitivity will take a dive. Maybe with True Technical debt (i.e. code that can be refactored to your understanding) you can fix and maintain. Messy code will just have to be abandoned eventually and can't be fixed.
Somehow I had this really deep feeling of ambivalence come over me reading this article.
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?
The difference is that, he claims, "making messes is never justified". Which is somewhat divorced from the reality of real world development that sometimes, even if you do everything right, comes down to firefighting, making the deadline at all costs, and doing what you're told even though you disagree with it.
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.
His heading is "Messes are not Acceptable"; my question is, acceptable to whom? Based on the priorities I get from my customers (/bosses), messes damn well are acceptable, and if they don't give me the time to fix them, what am I supposed to do about it?
Yes, I do endeavor not to make them in the first place but even after years of experience nobody can completely avoid them.
Not only that, but coding is an inherently messy business. Even if you are Uber-Coder. That's just the nature of the job.
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.
Perhaps what he's saying is that folks use the term "technical debt" as a fancy way of getting away with writing crappy code. When in fact technical debt is the stuff you couldn't have avoided if you wanted to, because you didn't know then what you know now.
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.
> technical debt is the stuff you couldn't have avoided if you wanted to, because you didn't know then what you know now.
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).
Now that I reread it, "[...] code that is clean enough to be able to refactor as you come to understand your problem" is a strange statement. Isn't refactoring just producing a cleaner version of the same solution?
I agree with your point. Ward asserts that one should invest in refactoring a piece of (clean) code if your understanding of the business model that drives it becomes more refined. This may or may not translate into more sustainable pace, however it avoids talking about the real killer of sustainable pace which is poorly written code.
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.
To me, the difference that Norton makes out between "technical debt" and "messes" is at most one of degrees and in no way fundamental.