7 ms·

Messy Code is not Technical Debt

20 points by mcantor 17y ago

mcantor 17y ago
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.
- Tichy 17y ago
  That's exactly how I think about "technical debt": it is a marketing buzzword invented by consultants to justify higher rates.
  - StrawberryFrog 17y ago
    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. In other words, it is a necessary term.
  - jerf 17y ago
    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".
    - Tichy 17y ago
      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.
      - mcantor 17y ago
        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!
- lallysingh 17y ago
  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."
timf 17y ago
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.
brazzy 17y ago
Who says that the person who originally came up with a catchy expression gets to decide what it means for all eternity? To me, the difference that Norton makes out between "technical debt" and "messes" is at most one of degrees and in no way fundamental.
- msluyter 17y ago
  Indeed, I think the post exhibits the "No True Scotsman" fallacy.
  - silentOpen 17y ago
    https://secure.wikimedia.org/wikipedia/en/wiki/No_True_Scotsman https://secure.wikimedia.org/wikipedia/en/wiki/No_True_Scots...
- jbm 17y ago
  Ditto. 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.
DanielBMarkham 17y ago
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?
- brazzy 17y ago
  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.
  - DanielBMarkham 17y ago
    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.
    - 17y ago
ZeroGravitas 17y ago
I see where he's going but I'm not sure I agree. 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.
edw519 17y ago
Technical Debt is accepted by many as a natural part of the development process. If you don't know how to avoid it, then calling it "natural" allows yourself off the hook from getting any better.
chubbard 17y ago
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. So we all agree messy code == toxic assets? :-)

20 points by mcantor 17y ago

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.

Tichy 17y ago
That's exactly how I think about "technical debt": it is a marketing buzzword invented by consultants to justify higher rates.
- StrawberryFrog 17y ago
  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. In other words, it is a necessary term.
- jerf 17y ago
  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".
  - Tichy 17y ago
    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.
    - mcantor 17y ago
      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!
lallysingh 17y ago
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."

timf 17y ago

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.

brazzy 17y ago

Who says that the person who originally came up with a catchy expression gets to decide what it means for all eternity? To me, the difference that Norton makes out between "technical debt" and "messes" is at most one of degrees and in no way fundamental.

msluyter 17y ago
Indeed, I think the post exhibits the "No True Scotsman" fallacy.
- silentOpen 17y ago
  https://secure.wikimedia.org/wikipedia/en/wiki/No_True_Scotsman https://secure.wikimedia.org/wikipedia/en/wiki/No_True_Scots...
jbm 17y ago
Ditto. 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.

DanielBMarkham 17y ago

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?

brazzy 17y ago
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.
- DanielBMarkham 17y ago
  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.
  - 17y ago

ZeroGravitas 17y ago

I see where he's going but I'm not sure I agree. 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.

edw519 17y ago

Technical Debt is accepted by many as a natural part of the development process. If you don't know how to avoid it, then calling it "natural" allows yourself off the hook from getting any better.

chubbard 17y ago

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. So we all agree messy code == toxic assets? :-)