5 ms·

Remember, kids: most of the software you have ever used is no longer functional. That browser you used 10 years ago doesn't run today. That server software you

Remember, kids: most of the software you have ever used is no longer functional. That browser you used 10 years ago doesn't run today. That server software you used 10 years ago is EOL today. Services come and go. Code dies. Do yourself a favor and plan the sunsetting of every piece of software and service that you use for your business. At the moment you start using it, plan how you will eventually move away from it. It always happens, and planning ahead leads to much fewer headaches. This applies to life in general, too; have an exit strategy.

rob_c 5y ago
speak for industry, in academia there is code still running from 20+ years ago which has been used for publications etc, not a lot but they exist and should be applauded.
nix23 5y ago
>Remember, kids: most of the software you have ever used is no longer functional. That browser you used 10 years ago doesn't run today. That server software you used 10 years ago is EOL today. Services come and go. Code dies. My Multics and MVS Tk4- runs pretty well, my DosBox and Nintendo Emulator too and hell have you checked FreeDOS? >Services come and go Yes >Code dies Don't have to.
mrits 5y ago
There are very few of us that have to deal with the headaches of our own choices. Even if you are staying at the same company for a decade there is a good chance you moved on to a different team.
bloopernova 5y ago
This is a great point. I was working with a DevOps team a couple of years ago and they had written some projects to deploy internal web apps to AWS. It came time to remove one of the apps, but the removal date kept slipping. After much hand wringing and meetings, it was discovered that they had no mechanism to uninstall one of their apps. They simply hadn't considered that an app might not be used anymore. Nor did they ever consider needing multiple instances of an app, so all their stuff was using hard coded names. It wasn't a fun project.
buscoquadnary 5y ago
That's funny. Grep, awk, sed, sort, uniq, emacs even. Most of these apps work and run and operate despite being old than me. Maybe the problem isn't that code eventually decays maybe the problem is the vision of what something is supposed to do is lost and then it has no place later on.
- bin_bash 5y ago
  That's because they're not part of a living, breathing, evolving ecosystem. They're great for what they are, but services on the internet need to be constantly maintained, upgraded, and monitored. It's not that our values as engineers have shifted, it's that old software was built on static platforms that rarely changed. New software has to constantly adapt to changing conditions in terms of security, stability, and performance.
nonameiguess 5y ago
This is actually kind of hilarious. In addition to the Unix examples here, this reminds me of my wife finding a 30 year-old Nintendo system complete with some old cartridges and an old controller. They were in a box since she was in college. Plugged it in and it still worked. Cloud-based services inevitably die, sure, but this is not true of software or machines in general. There's an entire YouTube genre of people finding and restoring cars that were built 30-90 years ago and abandoned for decades and getting them to run. We just don't build things to last any more, but a lot of that is by design. Subscriptions and planned obsolescence lead to more revenue. Atlassian could have built software that doesn't rot. Step 1 is don't get rid of the individual server licenses so people can self-host. Step 2 is probably don't use Java because eventually users will have to upgrade to a JVM that isn't compatible to avoid security problems. 64-bit ELF will probably work fine for another 60 years. Step 3 is open source it so users can build it themselves since you'll eventually hit binary incompatibility problems otherwise. Do all of that and there is no reason Jira couldn't be as durable as sed and grep.
- ElectricalUnion 5y ago
  > Step 2 is probably don't use Java because eventually users will have to upgrade to a JVM that isn't compatible to avoid security problems. 64-bit ELF will probably work fine for another 60 years. [Citation needed] I trust the managed language more in this regard. I don't know specifically the situation on the BSD side, but on Linux userland, once it uses anything that is not the Kernel or glibc, it's anyone's guess if the ELF will even run if not on the exact same packages on the same machine that compiled it.

rob_c 5y ago

speak for industry, in academia there is code still running from 20+ years ago which has been used for publications etc, not a lot but they exist and should be applauded.

nix23 5y ago

>Remember, kids: most of the software you have ever used is no longer functional. That browser you used 10 years ago doesn't run today. That server software you used 10 years ago is EOL today. Services come and go. Code dies. My Multics and MVS Tk4- runs pretty well, my DosBox and Nintendo Emulator too and hell have you checked FreeDOS? >Services come and go Yes >Code dies Don't have to.

mrits 5y ago

There are very few of us that have to deal with the headaches of our own choices. Even if you are staying at the same company for a decade there is a good chance you moved on to a different team.

bloopernova 5y ago

This is a great point. I was working with a DevOps team a couple of years ago and they had written some projects to deploy internal web apps to AWS. It came time to remove one of the apps, but the removal date kept slipping. After much hand wringing and meetings, it was discovered that they had no mechanism to uninstall one of their apps. They simply hadn't considered that an app might not be used anymore. Nor did they ever consider needing multiple instances of an app, so all their stuff was using hard coded names. It wasn't a fun project.

buscoquadnary 5y ago

That's funny. Grep, awk, sed, sort, uniq, emacs even. Most of these apps work and run and operate despite being old than me. Maybe the problem isn't that code eventually decays maybe the problem is the vision of what something is supposed to do is lost and then it has no place later on.

bin_bash 5y ago
That's because they're not part of a living, breathing, evolving ecosystem. They're great for what they are, but services on the internet need to be constantly maintained, upgraded, and monitored. It's not that our values as engineers have shifted, it's that old software was built on static platforms that rarely changed. New software has to constantly adapt to changing conditions in terms of security, stability, and performance.

nonameiguess 5y ago

This is actually kind of hilarious. In addition to the Unix examples here, this reminds me of my wife finding a 30 year-old Nintendo system complete with some old cartridges and an old controller. They were in a box since she was in college. Plugged it in and it still worked. Cloud-based services inevitably die, sure, but this is not true of software or machines in general. There's an entire YouTube genre of people finding and restoring cars that were built 30-90 years ago and abandoned for decades and getting them to run. We just don't build things to last any more, but a lot of that is by design. Subscriptions and planned obsolescence lead to more revenue. Atlassian could have built software that doesn't rot. Step 1 is don't get rid of the individual server licenses so people can self-host. Step 2 is probably don't use Java because eventually users will have to upgrade to a JVM that isn't compatible to avoid security problems. 64-bit ELF will probably work fine for another 60 years. Step 3 is open source it so users can build it themselves since you'll eventually hit binary incompatibility problems otherwise. Do all of that and there is no reason Jira couldn't be as durable as sed and grep.

ElectricalUnion 5y ago
> Step 2 is probably don't use Java because eventually users will have to upgrade to a JVM that isn't compatible to avoid security problems. 64-bit ELF will probably work fine for another 60 years. [Citation needed] I trust the managed language more in this regard. I don't know specifically the situation on the BSD side, but on Linux userland, once it uses anything that is not the Kernel or glibc, it's anyone's guess if the ELF will even run if not on the exact same packages on the same machine that compiled it.