4 ms·

Tech debt is more nuanced than explained by most analogies. In reality there is a lot of tech debt you can get away for free and never have to pay back. The co

Tech debt is more nuanced than explained by most analogies. In reality there is a lot of tech debt you can get away for free and never have to pay back. The code can be a mess but the functionality works and doesn't need updating. Other tech debt can infect and cripple a system if it isn't contained early. If you demonstrate that you know how to prioritize the most important tech debt then it is easier to convince management to work on it. The concept of doing more work now to make future easier is universal. Delivering on it is the hard part.

humanrebar 7y ago
If it never costs you anything, it's just a design decision, not technical debt. Plenty of projects never upgraded C versions, so old C is maybe not technical debt. But plenty of projects are upgrading python versions now, so old python is often technical debt.
- jwr 7y ago
  No, there is an important difference. It's technical debt because you might have to pay it back, but it might also turn out that you will be switching directions altogether and in that case the debt gets forgiven.
  - humanrebar 7y ago
    All code might need to be tweaked though. Even talking about stable C, the toolchain under it might become unsupported, requiring a port. That means every system include and compiler definition is technical debt.
    - thetedhogan 7y ago
      There's a difference between a toolchain becoming unsupported, and putting a hack around a feature that later becomes obsolete due to business decisions. That hack could certainly be technical debt, up until it isn't. If the code that it was implemented in is no longer used in the future, you didn't incur any cost to it. Not an original idea but I can't remember where I heard the idea. Technical debt is the best kind of debt, because it's the only debt that you might not have to pay back.
      - humanrebar 7y ago
        It doesn't have to be a hack to be technical debt. Anything with a shelf life, even out of date design, has risk and costs. The old python 2 is technical debt even if it wasn't a hack. Something needs to be done, it's just a question of what and when.

humanrebar 7y ago

If it never costs you anything, it's just a design decision, not technical debt. Plenty of projects never upgraded C versions, so old C is maybe not technical debt. But plenty of projects are upgrading python versions now, so old python is often technical debt.

jwr 7y ago
No, there is an important difference. It's technical debt because you might have to pay it back, but it might also turn out that you will be switching directions altogether and in that case the debt gets forgiven.
- humanrebar 7y ago
  All code might need to be tweaked though. Even talking about stable C, the toolchain under it might become unsupported, requiring a port. That means every system include and compiler definition is technical debt.
  - thetedhogan 7y ago
    There's a difference between a toolchain becoming unsupported, and putting a hack around a feature that later becomes obsolete due to business decisions. That hack could certainly be technical debt, up until it isn't. If the code that it was implemented in is no longer used in the future, you didn't incur any cost to it. Not an original idea but I can't remember where I heard the idea. Technical debt is the best kind of debt, because it's the only debt that you might not have to pay back.
    - humanrebar 7y ago
      It doesn't have to be a hack to be technical debt. Anything with a shelf life, even out of date design, has risk and costs. The old python 2 is technical debt even if it wasn't a hack. Something needs to be done, it's just a question of what and when.