4 ms·

I might have missed it, but missing from the taxonomy: "Pay In Full" Debt. In this debt, you pay the entire cost until the last use of it is cleaned up. This

I might have missed it, but missing from the taxonomy: "Pay In Full" Debt. In this debt, you pay the entire cost until the last use of it is cleaned up. This kind of debt is especially insidious because there is no incremental benefit to cleaning it up.

piinbinary 9y ago
I'd be curious to hear an example of that (I don't believe I have personally seen one that fits that pattern in the wild yet).
- cbanek 9y ago
  I'm not sure if it's "technical debt" but backward compatibility between versions can feel like this. Once you decide you stop supporting a previous version, you can rip out all that code (or strange compatibility code paths). Until then you're stuck with the whole thing.
- oculusthrift 9y ago
  removing a library? you can remove 100 usages of it but not until every single one is gone can you remove it.
  - TremendousJudge 9y ago
    porting to a backwards incompatible a language version? you can't use most of Python 3's new features while some part of your codebase is in Python 2
- logophobia 9y ago
  I used to work at a large software company. They had one giant monolith application, about a hundred different modules that did things from financial registration, displaying media. 30 years old, ported from clipper to delphi to .net. Lots of technical dept, but one issue fits the type of "pay-in-full". They only had a maximum of 3 gigs of ram to work with because the monolith was a 32 bits application. That was ok for most modules, but some did some rather complicated stuff that required more memory occasionally. It caused infrequent out-of-memory exceptions. The cause was one 32-bits library that was very hard to replace. It was used everywhere, and stored reports in a proprietary format, the company that made that library went out of business at some point, no source was available. The company prided itself on backwards compatibility, so it couldn't just dump the library without porting all the reports over. As far as I'm aware, it's still a 32 bits application.

piinbinary 9y ago

I'd be curious to hear an example of that (I don't believe I have personally seen one that fits that pattern in the wild yet).

cbanek 9y ago
I'm not sure if it's "technical debt" but backward compatibility between versions can feel like this. Once you decide you stop supporting a previous version, you can rip out all that code (or strange compatibility code paths). Until then you're stuck with the whole thing.
oculusthrift 9y ago
removing a library? you can remove 100 usages of it but not until every single one is gone can you remove it.
- TremendousJudge 9y ago
  porting to a backwards incompatible a language version? you can't use most of Python 3's new features while some part of your codebase is in Python 2
logophobia 9y ago
I used to work at a large software company. They had one giant monolith application, about a hundred different modules that did things from financial registration, displaying media. 30 years old, ported from clipper to delphi to .net. Lots of technical dept, but one issue fits the type of "pay-in-full". They only had a maximum of 3 gigs of ram to work with because the monolith was a 32 bits application. That was ok for most modules, but some did some rather complicated stuff that required more memory occasionally. It caused infrequent out-of-memory exceptions. The cause was one 32-bits library that was very hard to replace. It was used everywhere, and stored reports in a proprietary format, the company that made that library went out of business at some point, no source was available. The company prided itself on backwards compatibility, so it couldn't just dump the library without porting all the reports over. As far as I'm aware, it's still a 32 bits application.