5 ms·

Technical debt is a great metaphor because it is easy to understand for management. Calling code "a mess" does not really communicate why it should be improved

by goto11 6y ago

Technical debt is a great metaphor because it is easy to understand for management. Calling code "a mess" does not really communicate why it should be improved. Who cares if it is a mess if it works? What developers actually mean with "a mess" is that the code gets increasingly harder to maintain which incurs cost down the road. Technical debt is a good metaphor to explain this.

mewpmewp2 6y ago
Exactly. This is not a term for developers. It is to explain tradeoffs or current state for anyone looking at the big picture. I think the article is misunderstanding that we makes the whole article moot.
- erikpukinskis 6y ago
  I’ve been working on a project at work to try to measure the interest paid on technical debt. And I think developers are the only people who can really measure that. Their time is the cost. The only way to understand how much of it is paying principal, how much is paying interest, and how much of it is just “buying stuff we actually need” comes down to having that conversation with the engineers. One of the big things I’ve learned speaks to your point though: it’s not a natural way of thinking for most engineers. There are a few who are “natural complainers” who can tell the difference between “work that needs to be done” and “work I have to do because someone took a shortcut in the past”. But actually many of the “natural complainers”, while they have strong “this is insane” detectors, they often complain about anything that’s not perfect. But that’s not exactly what we want. Many things are not perfect but they’re pretty easy to work around. That’s not an interest payment it’s just an annoyance. And on the other side of the spectrum there are a lot of coders who have a “whatever it takes” mindset, and they can’t really perceive interest paid at all. To them, every necessary thing is reasonable. If it has to be done it has to be done. They don’t really think about how it could be done more easily in a different world... because we’re not in that world! Why think about a hypothetical! So, I have some more thinking to do about how to teach folks to think critically about their time and past decisions. And the other big learning I got is the recording of interest payments is only useful if it’s somewhat regular. So I think it has to be an official, required part of the production process. If people have to remember to report on interest paid, they just won’t. The project is on pause right now, but I’d like to give it another shot with those things in mind. I think I’m going to wait until a time when it feels like it fits in with the needs of the managers though. Otherwise that second piece of “part of the process” is gonna be hard. But if I can at least put an “interest paid” number on some tasks, my hope is that will provide a good way to identify which projects will “pay off” if they are “paid off”. Basically I want a vaguely rigorous way to put refractors and infrastructure work up against new features so they can be compared 1:1 during planning. Also feel free to email me if anyone is interested in something like this at their company.
  - deleted 6y ago
    [deleted]
user5994461 6y ago
Technical debt is a terrible metaphor because it is readily misunderstood by management. Debt is a great thing (financial debt). You can get free things now and pay for them later. Or never pay because you're changing company anyway. (That's what MBA managers understand) Also, debt in software is inevitable. Every developer that comes in say everything is debt, and the next one will invariably says the same thing about his predecessor. It's as if everything ever done is debt, might as well ignore these guys. (That's what managers interacting with developers quickly come to understand)
d0mine 6y ago
A silver lining for the current pandemic is that more people might learn the word "exponent". Technical debt is misleading. A better term is a time bomb (fixing consequences might be exponentially harder than the original issue).
- srtjstjsj 6y ago
  www.castsoftware.com/blog/bad-code-isnt-technical-debt-its-an-unhedged-call-option (2014)
  - d0mine 6y ago
    The original is probably this: https://www.higherorderlogic.com/2010/07/23/bad-code-isnt-technical-debt-its-an-unhedged-call-option/ https://www.higherorderlogic.com/2010/07/23/bad-code-isnt-te... Previous discussion: https://news.ycombinator.com/item?id=8777237 https://news.ycombinator.com/item?id=8777237

by goto11 6y ago

mewpmewp2 6y ago

Exactly. This is not a term for developers. It is to explain tradeoffs or current state for anyone looking at the big picture. I think the article is misunderstanding that we makes the whole article moot.

erikpukinskis 6y ago
I’ve been working on a project at work to try to measure the interest paid on technical debt. And I think developers are the only people who can really measure that. Their time is the cost. The only way to understand how much of it is paying principal, how much is paying interest, and how much of it is just “buying stuff we actually need” comes down to having that conversation with the engineers. One of the big things I’ve learned speaks to your point though: it’s not a natural way of thinking for most engineers. There are a few who are “natural complainers” who can tell the difference between “work that needs to be done” and “work I have to do because someone took a shortcut in the past”. But actually many of the “natural complainers”, while they have strong “this is insane” detectors, they often complain about anything that’s not perfect. But that’s not exactly what we want. Many things are not perfect but they’re pretty easy to work around. That’s not an interest payment it’s just an annoyance. And on the other side of the spectrum there are a lot of coders who have a “whatever it takes” mindset, and they can’t really perceive interest paid at all. To them, every necessary thing is reasonable. If it has to be done it has to be done. They don’t really think about how it could be done more easily in a different world... because we’re not in that world! Why think about a hypothetical! So, I have some more thinking to do about how to teach folks to think critically about their time and past decisions. And the other big learning I got is the recording of interest payments is only useful if it’s somewhat regular. So I think it has to be an official, required part of the production process. If people have to remember to report on interest paid, they just won’t. The project is on pause right now, but I’d like to give it another shot with those things in mind. I think I’m going to wait until a time when it feels like it fits in with the needs of the managers though. Otherwise that second piece of “part of the process” is gonna be hard. But if I can at least put an “interest paid” number on some tasks, my hope is that will provide a good way to identify which projects will “pay off” if they are “paid off”. Basically I want a vaguely rigorous way to put refractors and infrastructure work up against new features so they can be compared 1:1 during planning. Also feel free to email me if anyone is interested in something like this at their company.
- deleted 6y ago
  [deleted]

user5994461 6y ago

Technical debt is a terrible metaphor because it is readily misunderstood by management. Debt is a great thing (financial debt). You can get free things now and pay for them later. Or never pay because you're changing company anyway. (That's what MBA managers understand) Also, debt in software is inevitable. Every developer that comes in say everything is debt, and the next one will invariably says the same thing about his predecessor. It's as if everything ever done is debt, might as well ignore these guys. (That's what managers interacting with developers quickly come to understand)

d0mine 6y ago

A silver lining for the current pandemic is that more people might learn the word "exponent". Technical debt is misleading. A better term is a time bomb (fixing consequences might be exponentially harder than the original issue).

srtjstjsj 6y ago
www.castsoftware.com/blog/bad-code-isnt-technical-debt-its-an-unhedged-call-option (2014)
- d0mine 6y ago
  The original is probably this: https://www.higherorderlogic.com/2010/07/23/bad-code-isnt-technical-debt-its-an-unhedged-call-option/ https://www.higherorderlogic.com/2010/07/23/bad-code-isnt-te... Previous discussion: https://news.ycombinator.com/item?id=8777237 https://news.ycombinator.com/item?id=8777237