4 ms·

Shameless plug: I also wrote about how we have overused the term "Tech debt". The concept of "debt" for me should include some sort of "investment" - ie you don

Shameless plug: I also wrote about how we have overused the term "Tech debt". The concept of "debt" for me should include some sort of "investment" - ie you don't do something well because you need or you want to invest the time on something else. But if something is done with plain bad code, it shouldn't be called tech debt. Something that outgrew its objective shouldn't be called tech debt. If something is a bug it shouldn't be called tech debt. https://isidoro.io/writing/tech-debt-broken-windows/ https://isidoro.io/writing/tech-debt-broken-windows/

dec0dedab0de 6y ago
Something that outgrew its objective shouldn't be called tech debt I agree with the rest of your comment, but something that outgrew its objective is almost text book tech debt. Instead of taking the time to build something new, or refactoring, you tacked it on to something existing.
- sergioisidoro 6y ago
  Yes, I understand your point. But in my writing I was a bit pedantic in defining that you only take debt deliberately and with a repayment plan. If you build something properly (ie you did not deliberately made a choice of taking a shortcut), and it ages badly I called it Tech rot.
  - warlog 6y ago
    I think the idea of short-term vs long-term tradeoff is key. And whether you chose the short-term option decisively or naively, doesn't alter the fact that the tradeoff existed.
    - deleted 6y ago
      [deleted]
magicalhippo 6y ago
Technical debt also manifests itself differently. Some of it might not be felt on a daily basis, but acts more like extra mass or like drag, impeding acceleration. That is slowing you down when making or changing stuff. This is in contrast to the debt you have to pay each day in production. We have a fair bit of that "extra mass", due to shortcuts taken many moons ago under tight deadlines. On a daily basis the code works fine, and does what the customer needs. However due to it we spend extra time when we need to extend it or change it.
supernovae 6y ago
I think the whole thing is hogwash. Debt is an instrument of contract, nothing more, nothing less. It's packaged, legally binding and sold on the markets. There is nothing good or bad about it, it is what it is on its own. Even thinking in terms of "investment" is gap thinking and treats human systems without human traits. In a system of joint activity, people and artefacts work together in harmony. If they're not working together, it's not joint activity and if its not joint activity, that doesn't mean its debt either. It's dysfunctional.
webmaven 6y ago
> But if something is done with plain bad code, it shouldn't be called tech debt. Something that outgrew its objective shouldn't be called tech debt. If something is a bug it shouldn't be called tech debt. I don't think anyone refers to bugs as technical debt per-se. What I have seen is bugs that result from technical debt, and hasty bug fixes that create more technical debt.
proto-n 6y ago
Well on an organizational level badly written code is imo tech debt. It's worse quality in exchange for paying less money (paying less capable / inexperienced devs).

dec0dedab0de 6y ago

Something that outgrew its objective shouldn't be called tech debt I agree with the rest of your comment, but something that outgrew its objective is almost text book tech debt. Instead of taking the time to build something new, or refactoring, you tacked it on to something existing.

sergioisidoro 6y ago
Yes, I understand your point. But in my writing I was a bit pedantic in defining that you only take debt deliberately and with a repayment plan. If you build something properly (ie you did not deliberately made a choice of taking a shortcut), and it ages badly I called it Tech rot.
- warlog 6y ago
  I think the idea of short-term vs long-term tradeoff is key. And whether you chose the short-term option decisively or naively, doesn't alter the fact that the tradeoff existed.
  - deleted 6y ago
    [deleted]

magicalhippo 6y ago

Technical debt also manifests itself differently. Some of it might not be felt on a daily basis, but acts more like extra mass or like drag, impeding acceleration. That is slowing you down when making or changing stuff. This is in contrast to the debt you have to pay each day in production. We have a fair bit of that "extra mass", due to shortcuts taken many moons ago under tight deadlines. On a daily basis the code works fine, and does what the customer needs. However due to it we spend extra time when we need to extend it or change it.

supernovae 6y ago

I think the whole thing is hogwash. Debt is an instrument of contract, nothing more, nothing less. It's packaged, legally binding and sold on the markets. There is nothing good or bad about it, it is what it is on its own. Even thinking in terms of "investment" is gap thinking and treats human systems without human traits. In a system of joint activity, people and artefacts work together in harmony. If they're not working together, it's not joint activity and if its not joint activity, that doesn't mean its debt either. It's dysfunctional.

webmaven 6y ago

> But if something is done with plain bad code, it shouldn't be called tech debt. Something that outgrew its objective shouldn't be called tech debt. If something is a bug it shouldn't be called tech debt. I don't think anyone refers to bugs as technical debt per-se. What I have seen is bugs that result from technical debt, and hasty bug fixes that create more technical debt.

proto-n 6y ago

Well on an organizational level badly written code is imo tech debt. It's worse quality in exchange for paying less money (paying less capable / inexperienced devs).