5 ms·

Everything is supposed to decay. But software is effectively immortal, and that's the root of this problem. We need to introduce decay into software systems, or

Everything is supposed to decay. But software is effectively immortal, and that's the root of this problem. We need to introduce decay into software systems, or we end up with zombies that are too useful to let die. We should allow software to die. It's okay. Whenever a generation feels like they can't lose the artifacts of the previous generation, civilization is in decline. Which is okay too, except when technology protects those artifacts too well, which I believe usually hastens the end.

javajosh 6y ago
*The exception, of course, is Google Reader.
- craftinator 6y ago
  Oh good, your comment just made me laugh milk out my nose. Bravo sir, and thank you for that excellent gem!
0xffff2 6y ago
I'm not sure I understand this comment. Could you give some examples of "zombies that are too useful to let die" right now?
- deleted 6y ago
  [deleted]
- theshrike79 6y ago
  There are tons of programs related to moving money from one place to another, all written in COBOL or Fortran at the time when men wore hats and smoked indoors. First they were kept alive by cobbling together new hardware to keep the old monster running. Then they were moved to virtualized environments that emulated the original hardware with all its weirdnesses and glitch. These are the zombies we're talking about. The useful living dead. We feed them their pound of flesh every now and again in the form of coders who can still speak the ancient incantations, but otherwise we keep them in the basement toiling away. We don't touch them because we are too afraid. No one dares to take the responsibility of rewriting all that code that still works, no matter the cost.
  - isbvhodnvemrwvn 6y ago
    Anything travel related as well. Somebody in the 1980s thought that being able to read your order with just your surname as a password was a good idea. Or that passwords have to be 8 character maximum, no profanities or common words, and they can't have Y or some other characters since you could not have dialed it on a specific model of 1980s phone. I haven't touched a GDS for the past 10 years or so, but they are out there, probably still on mainframes as well.
  - 0xffff2 6y ago
    And what's the alternative? We rewrite the whole stack in Java/C++/C# this year, and in 20 years we rewrite the whole thing again in Rust? That really doesn't seem like an improvement to me.
    - theshrike79 6y ago
      The alternative would be to keep the code fresh. If you let it stagnate, the hidden knowledge on how and - more importantly - WHY it does things gets lost. If you write it once and fire all the programmers, every update is a huge undertaking with immense risks. But if you keep reiterating and refactoring it slowly over time, the code stays fresh and the knowledge isn't lost. You might change the language stack for the whole product during the iterations, maybe just use a fresh stack for a part of it. Maybe keep the old tech, but make it more readable and easier to integrate with other systems.
    - Too 6y ago
      Same thing happens everywhere. Fire code, regulations and other best practices improve and we don't use asbestos, leaded pipes or non-grounded electricity to build houses anymore, despite how good and convenient it was 30 years ago. Now you could still live in such an old house today and be happy but the moment you remodel and tear down that asbestos wall you will need to sanitize the whole thing from dangerous particles. Same thing with old programming languages, they don't have the same guard rails as today so once you start tearing up old dust there could be invisible demons awaiting, especially if done by people with limited experience in such environment.
the_other 6y ago
> We need to introduce decay into software systems, or we end up with zombies that are too useful to let die. We already have this. Just today I read on another post on here how someone had to stop using their 32-bit audio plugins because their OS stopped supporting 32-bit. That software wasn't "fit enough" to survive in the current environment, so it was selected against. It died. Its entire species (its copies) died out. The really interesting discussion, I think, is "what is software"? Where does its boundary end? The 32-bit app died because the team that built it couldn't/didn't update it to 64-bit. It didn't die because it stopped working for the environment it was built for. It died because of money and people, not bits and transistors. Why was that? What happened to the team? What's the lesson? Should the plug-in have been made in the first place? Does it matter? If the "death" is due to people and money more than bits, where's the boundary the remarks "software". What should we let die (copies of bits, or teams?) and how does that look? For me, all this leads into economics, wealth distribution, resource sharing, leadership. The "real" software?
webmaven 6y ago
> Everything is supposed to decay. But software is effectively immortal, and that's the root of this problem. We need to introduce decay into software systems, or we end up with zombies that are too useful to let die. > We should allow software to die. It's okay. Whenever a generation feels like they can't lose the artifacts of the previous generation, civilization is in decline. Which is okay too, except when technology protects those artifacts too well, which I believe usually hastens the end. I don't think this will be a problem, over the long term. the average life-span of companies listed in S&P 500 was 61 years in 1958. The current average is under 18 years. As long as that code is helping to keep it's hosts alive, it will keep being run. When the remaining hosts die, the code will die too. 60 years from now, someone will be having this discussion about having to keep a virtualized instance of AWS running, complete with all the CPU, GPU, and networking bugs, just to keep some crucial bitcoin clearinghouse that no-one understands anymore running. Heck, maybe it will be even weirder, like, what if GMail ends up being that sort of zombie infrastructure, and it stops working if there is no more spam? We'll have to set up a dedicated AI to create and send spam just to keep the last demi-sentient instance of Gmail running without having an existential meltdown. I'm reasonably sure that by that point, COBOL itself won't be a problem anymore, there simply won't be any companies that still depend on it left.

javajosh 6y ago

*The exception, of course, is Google Reader.

craftinator 6y ago
Oh good, your comment just made me laugh milk out my nose. Bravo sir, and thank you for that excellent gem!

0xffff2 6y ago

I'm not sure I understand this comment. Could you give some examples of "zombies that are too useful to let die" right now?

deleted 6y ago
[deleted]
theshrike79 6y ago
There are tons of programs related to moving money from one place to another, all written in COBOL or Fortran at the time when men wore hats and smoked indoors. First they were kept alive by cobbling together new hardware to keep the old monster running. Then they were moved to virtualized environments that emulated the original hardware with all its weirdnesses and glitch. These are the zombies we're talking about. The useful living dead. We feed them their pound of flesh every now and again in the form of coders who can still speak the ancient incantations, but otherwise we keep them in the basement toiling away. We don't touch them because we are too afraid. No one dares to take the responsibility of rewriting all that code that still works, no matter the cost.
- isbvhodnvemrwvn 6y ago
  Anything travel related as well. Somebody in the 1980s thought that being able to read your order with just your surname as a password was a good idea. Or that passwords have to be 8 character maximum, no profanities or common words, and they can't have Y or some other characters since you could not have dialed it on a specific model of 1980s phone. I haven't touched a GDS for the past 10 years or so, but they are out there, probably still on mainframes as well.
- 0xffff2 6y ago
  And what's the alternative? We rewrite the whole stack in Java/C++/C# this year, and in 20 years we rewrite the whole thing again in Rust? That really doesn't seem like an improvement to me.
  - theshrike79 6y ago
    The alternative would be to keep the code fresh. If you let it stagnate, the hidden knowledge on how and - more importantly - WHY it does things gets lost. If you write it once and fire all the programmers, every update is a huge undertaking with immense risks. But if you keep reiterating and refactoring it slowly over time, the code stays fresh and the knowledge isn't lost. You might change the language stack for the whole product during the iterations, maybe just use a fresh stack for a part of it. Maybe keep the old tech, but make it more readable and easier to integrate with other systems.
  - Too 6y ago
    Same thing happens everywhere. Fire code, regulations and other best practices improve and we don't use asbestos, leaded pipes or non-grounded electricity to build houses anymore, despite how good and convenient it was 30 years ago. Now you could still live in such an old house today and be happy but the moment you remodel and tear down that asbestos wall you will need to sanitize the whole thing from dangerous particles. Same thing with old programming languages, they don't have the same guard rails as today so once you start tearing up old dust there could be invisible demons awaiting, especially if done by people with limited experience in such environment.

the_other 6y ago

> We need to introduce decay into software systems, or we end up with zombies that are too useful to let die. We already have this. Just today I read on another post on here how someone had to stop using their 32-bit audio plugins because their OS stopped supporting 32-bit. That software wasn't "fit enough" to survive in the current environment, so it was selected against. It died. Its entire species (its copies) died out. The really interesting discussion, I think, is "what is software"? Where does its boundary end? The 32-bit app died because the team that built it couldn't/didn't update it to 64-bit. It didn't die because it stopped working for the environment it was built for. It died because of money and people, not bits and transistors. Why was that? What happened to the team? What's the lesson? Should the plug-in have been made in the first place? Does it matter? If the "death" is due to people and money more than bits, where's the boundary the remarks "software". What should we let die (copies of bits, or teams?) and how does that look? For me, all this leads into economics, wealth distribution, resource sharing, leadership. The "real" software?

webmaven 6y ago

> Everything is supposed to decay. But software is effectively immortal, and that's the root of this problem. We need to introduce decay into software systems, or we end up with zombies that are too useful to let die. > We should allow software to die. It's okay. Whenever a generation feels like they can't lose the artifacts of the previous generation, civilization is in decline. Which is okay too, except when technology protects those artifacts too well, which I believe usually hastens the end. I don't think this will be a problem, over the long term. the average life-span of companies listed in S&P 500 was 61 years in 1958. The current average is under 18 years. As long as that code is helping to keep it's hosts alive, it will keep being run. When the remaining hosts die, the code will die too. 60 years from now, someone will be having this discussion about having to keep a virtualized instance of AWS running, complete with all the CPU, GPU, and networking bugs, just to keep some crucial bitcoin clearinghouse that no-one understands anymore running. Heck, maybe it will be even weirder, like, what if GMail ends up being that sort of zombie infrastructure, and it stops working if there is no more spam? We'll have to set up a dedicated AI to create and send spam just to keep the last demi-sentient instance of Gmail running without having an existential meltdown. I'm reasonably sure that by that point, COBOL itself won't be a problem anymore, there simply won't be any companies that still depend on it left.