4 ms·

There has to be a term for when the business builds something with one tech stack, and then later, as if it was totally by surprise, realizes it needs to replac

There has to be a term for when the business builds something with one tech stack, and then later, as if it was totally by surprise, realizes it needs to replace the whole thing, for basically no added business-value, and this happens every few years. I mean, everyone has known they would have to do this eventually, but it just kept being put off, like the business is a bad procrastinator. And they all do this.

whitten 7y ago
I assume you are referring to "technical debt", unless you were being ironic and I didn't catch your irony emoji. (Is there an ironic emoji?)
- riffraff 7y ago
  there almost is, an irony mark or percontation point "⸮" https://en.wikipedia.org/wiki/Irony_punctuation https://en.wikipedia.org/wiki/Irony_punctuation
- badfrog 7y ago
  I don't think that quite applies. Technical debt comes from making choices that help you in the short term but cost you more in the long run (i.e. you're paying interest). Needing to move off a deprecated tech stack wouldn't really qualify unless there was a longer-term option available at the time you originally decided on your tech stack.
- slightwinder 7y ago
  Would it really be technical debt when we talk about transition from py2->py3? Technical debt is about the consequences of bad design. But py3 is more the consequence of growth and gain of experience. And for a company it is an external debt. I would call it more something like upgrade debt or time debt, as it's a problem that appeared because an external situation changed over time. Similar problem in that regard are operating systems which change and let old software behind, or in case of linux old packages not working anymore, repos disappearing, etc.
  - bryanrasmussen 7y ago
    py2 to py3 would be handling the technical depreciation of value.
- peterwwillis 7y ago
  This is different. Tech debt is a factor of letting things get slowly worse. Those things can be improved if you just work on your tech debt. What I'm talking about can't be improved or fixed, or higher-ups refuse to improve or fix it. Instead, it has to be completely replaced. It's like a Replicant with a four-year lifespan. You literally know it's going to die in four years, and nobody orders a new one until the old one is practically dead, and everyone has to rush to replace it.
  - agustif 7y ago
    Sounds like Egyptian emperors and pyramids
S_A_P 7y ago
stack underflow.
specialist 7y ago
Same as every other industry. Being a CADD person, I had a lot of contact with A/E/C, facilities management, space planning, etc. Seems like everyone suffers legacy, neglects maintenance, prefers do overs. Cultural? Misaligned incentives? Bad accounting? Complexity catastrophe (when cost of any change outweighs benefits)? If someone knows, please tell.
- Spooky23 7y ago
  It's always easier and sexier to build than maintain. All capital expense decisions are made at a point in time. Sustained operations are hard unless you have growth, because flat budgets are cuts given inflation, etc. Given the choice between stocking the toilet paper or doing a preventative maintenance on the elevator that may impact your successor a few years from now, what do you choose? The only times that facilities are run well is when there is a retired senior military nco in charge. Usually someone who was a chief of the boat in the Navy.
  - specialist 7y ago
    I hadn't thought to mine knowledge from old seadogs, a la Peter Drucker. Thanks.
bryanrasmussen 7y ago
When I was working for Thomson Reuters WestLaw they sold the Danish/Swedish holdings and we had to move off the platform we had just spent a year moving onto (the sale happened about 7 months after the move was completed), we had one year to move off or we would have had to pay approximately $180,000 a month for using their platform (approximately as being represented in DKK not USD), of course we managed the move and also managed quite a lot of added business value.
lostcolony 7y ago
It's just delaying maintenance. We're bad at recognizing that software requires maintenance and periodic updates/replacement, same as anything physical. Businesses think once it's written it will always just work...and that's true if the underlying OS and hardware never change, and the business never changes, and requirements never change. But even if it's a completely niche application whose requirements never change, after a while the hardware breaks, and we can't buy the same, and we can't license the old OS or it has documented problems that won't be fixed, so we have to use a new one, and we can't get the old software dependencies to work on the new one, etc etc.
- strbean 7y ago
  Add to that list "and there is basically one guy still qualified to work on the system", which is practically the case now for old COBOL banking systems. See http://cobolcowboys.com/ http://cobolcowboys.com/
- hnick 7y ago
  The software version of driving a car until it falls apart instead of doing more than the bare minimum to keep it running. It's not always the wrong choice but it's wrong to be surprised when faced with the expected outcome.

whitten 7y ago

I assume you are referring to "technical debt", unless you were being ironic and I didn't catch your irony emoji. (Is there an ironic emoji?)

riffraff 7y ago
there almost is, an irony mark or percontation point "⸮" https://en.wikipedia.org/wiki/Irony_punctuation https://en.wikipedia.org/wiki/Irony_punctuation
badfrog 7y ago
I don't think that quite applies. Technical debt comes from making choices that help you in the short term but cost you more in the long run (i.e. you're paying interest). Needing to move off a deprecated tech stack wouldn't really qualify unless there was a longer-term option available at the time you originally decided on your tech stack.
slightwinder 7y ago
Would it really be technical debt when we talk about transition from py2->py3? Technical debt is about the consequences of bad design. But py3 is more the consequence of growth and gain of experience. And for a company it is an external debt. I would call it more something like upgrade debt or time debt, as it's a problem that appeared because an external situation changed over time. Similar problem in that regard are operating systems which change and let old software behind, or in case of linux old packages not working anymore, repos disappearing, etc.
- bryanrasmussen 7y ago
  py2 to py3 would be handling the technical depreciation of value.
peterwwillis 7y ago
This is different. Tech debt is a factor of letting things get slowly worse. Those things can be improved if you just work on your tech debt. What I'm talking about can't be improved or fixed, or higher-ups refuse to improve or fix it. Instead, it has to be completely replaced. It's like a Replicant with a four-year lifespan. You literally know it's going to die in four years, and nobody orders a new one until the old one is practically dead, and everyone has to rush to replace it.
- agustif 7y ago
  Sounds like Egyptian emperors and pyramids

S_A_P 7y ago

stack underflow.

specialist 7y ago

Same as every other industry. Being a CADD person, I had a lot of contact with A/E/C, facilities management, space planning, etc. Seems like everyone suffers legacy, neglects maintenance, prefers do overs. Cultural? Misaligned incentives? Bad accounting? Complexity catastrophe (when cost of any change outweighs benefits)? If someone knows, please tell.

Spooky23 7y ago
It's always easier and sexier to build than maintain. All capital expense decisions are made at a point in time. Sustained operations are hard unless you have growth, because flat budgets are cuts given inflation, etc. Given the choice between stocking the toilet paper or doing a preventative maintenance on the elevator that may impact your successor a few years from now, what do you choose? The only times that facilities are run well is when there is a retired senior military nco in charge. Usually someone who was a chief of the boat in the Navy.
- specialist 7y ago
  I hadn't thought to mine knowledge from old seadogs, a la Peter Drucker. Thanks.

bryanrasmussen 7y ago

When I was working for Thomson Reuters WestLaw they sold the Danish/Swedish holdings and we had to move off the platform we had just spent a year moving onto (the sale happened about 7 months after the move was completed), we had one year to move off or we would have had to pay approximately $180,000 a month for using their platform (approximately as being represented in DKK not USD), of course we managed the move and also managed quite a lot of added business value.

lostcolony 7y ago

It's just delaying maintenance. We're bad at recognizing that software requires maintenance and periodic updates/replacement, same as anything physical. Businesses think once it's written it will always just work...and that's true if the underlying OS and hardware never change, and the business never changes, and requirements never change. But even if it's a completely niche application whose requirements never change, after a while the hardware breaks, and we can't buy the same, and we can't license the old OS or it has documented problems that won't be fixed, so we have to use a new one, and we can't get the old software dependencies to work on the new one, etc etc.

strbean 7y ago
Add to that list "and there is basically one guy still qualified to work on the system", which is practically the case now for old COBOL banking systems. See http://cobolcowboys.com/ http://cobolcowboys.com/
hnick 7y ago
The software version of driving a car until it falls apart instead of doing more than the bare minimum to keep it running. It's not always the wrong choice but it's wrong to be surprised when faced with the expected outcome.