4 ms·

It's not "gone", it served its purpose. Software is born, lives, and dies. By the time a project is 3-4 years old, unless it is a core central service, the busi

It's not "gone", it served its purpose. Software is born, lives, and dies. By the time a project is 3-4 years old, unless it is a core central service, the business (if it is competing successfully) has most likely moved far beyond the initial assumptions laid out at its' creation.

compiler-guy 4y ago
Don't know what kind of projects you are working on, but in the world where I work, source-code that is literally decades old is common, and companies pay extremely good money for people who understand it. This includes things like airline reservation systems, scientific computing models, compilers for obscure dsls, and the like.
tyre 4y ago
If a business is competing successfully I don’t think you’re going to see software obviated every three years. Software isn’t like living beings that up and die. They evolve over time. Companies doing rewrites every three years have a hard ceiling.
marcosdumay 4y ago
> it served its purpose That's a blind jump. We don't know the purpose, we don't know how much was invested, how much was already recovered, and how much more could be earned if the program was allowed to live. All we know is that it has recently hit fitness to purpose, and that the fitness caused it to be abandoned.
guntherhermann 4y ago
It sounds like you haven't been in the situation the parent is describing. I have and still am. We have stuck one ancient piece of software in a docker container and have our fingers crossed that it continues to work. This software is OLD, early Perl 5 old. Nobody in the department understands Perl or wants to. The business (read: product owner) has deemed it unimportant to update or understand, but I assure you that if it stopped working, it would affect millions of tax payers, upper management would find out (read: VP, CEO), and heads would roll. Everything is fine, until it isn't. Your thinking from the perspective of a startup might be true, but from the perspective of a company that is many decades old and has a dozen layers of management... perhaps not so much
- ramesh31 4y ago
  >It sounds like you haven't been in the situation the parent is describing. Sure I have. And the first few times I too thought that it mattered. But it doesn't. None of the stuff we care about as software developers actually matters. We are just pawns for the people making money decisions. Completely replaceable automatons. If what you are doing is not directly supporting a strategic business goal, you are doing nothing but costing a business money. And cost centers are the first to be cut. You can sit there with your sense of self importance, thinking that the cleanliness and elegance of your code matters. But it just doesn't. Nobody cares. And the sooner you let go of thinking it matters the sooner you can focus your effort on what does. The reality is that when whatever old house of cards you're running fails for whatever reason, the business will switch to a vendor that covers 95% of the use case, while being much cheaper and not requiring FTE support. It will be a tiny bump in the road for the business, replacing this thing that you thought was a world beating make or break technology.
- Micoloth 4y ago
  That's amazing! Can you share more about what sector you are working in and what the software in question does?
- WesolyKubeczek 4y ago
  The problem that your product owner cannot see any value in replacing/understanding/modernizing that piece of software, but should it fail, the heads would roll, speaks of a bigger problem in your organization than an ancient piece of software. You have been able to put it in a container and it’s running, so unless the kernel itself changes drastically so old libc will just stop working, it’s going to be able to work unchanged for a decade more. But the communications problem between management layers is way bigger than that, and could probably bite in some other situation.
- intrasight 4y ago
  What would be an example of such a software company? I am always faced with this issue with non-software companies in industries where I've worked such as nuclear, defense, energy, and healthcare. At these places, I've confronted "hands-off" modules that are effectively black boxes of complex logic that has been vetted over decades, is written in C or Fortran, and nobody is allowed to modify. I can't imagine that situation existing in a software company.
alex-nt 4y ago
Fun story about the 3-4Y window, one of the execs at my company was having a Q&A, and he gave an example in another question a new set of components, saying that he expects them to be in use for the next 20Y. I asked why does he think he can keep the know-how and outsmart the competition (components were part of algo trading and other trading related things) for the next 20y with just this investment, and he just downplayed my question as an IT guy wanting more money/work. ¯\_(ツ)_/¯
giaour 4y ago
3-4 years is very short as far as software lifespans go. Software libraries that are 10-15 years old are commonplace in both open source and at FAANGs, and some industries practice "extreme longevity": any domain where you wouldn't be surprised to run into a mainframe is probably also running code with a 30 year+ lineage.
- andrewf 4y ago
  I don't think it's a coincidence that software lifetime has converged to the time it takes an initial stock grant to vest.

compiler-guy 4y ago

Don't know what kind of projects you are working on, but in the world where I work, source-code that is literally decades old is common, and companies pay extremely good money for people who understand it. This includes things like airline reservation systems, scientific computing models, compilers for obscure dsls, and the like.

tyre 4y ago

If a business is competing successfully I don’t think you’re going to see software obviated every three years. Software isn’t like living beings that up and die. They evolve over time. Companies doing rewrites every three years have a hard ceiling.

marcosdumay 4y ago

> it served its purpose That's a blind jump. We don't know the purpose, we don't know how much was invested, how much was already recovered, and how much more could be earned if the program was allowed to live. All we know is that it has recently hit fitness to purpose, and that the fitness caused it to be abandoned.

guntherhermann 4y ago

It sounds like you haven't been in the situation the parent is describing. I have and still am. We have stuck one ancient piece of software in a docker container and have our fingers crossed that it continues to work. This software is OLD, early Perl 5 old. Nobody in the department understands Perl or wants to. The business (read: product owner) has deemed it unimportant to update or understand, but I assure you that if it stopped working, it would affect millions of tax payers, upper management would find out (read: VP, CEO), and heads would roll. Everything is fine, until it isn't. Your thinking from the perspective of a startup might be true, but from the perspective of a company that is many decades old and has a dozen layers of management... perhaps not so much

ramesh31 4y ago
>It sounds like you haven't been in the situation the parent is describing. Sure I have. And the first few times I too thought that it mattered. But it doesn't. None of the stuff we care about as software developers actually matters. We are just pawns for the people making money decisions. Completely replaceable automatons. If what you are doing is not directly supporting a strategic business goal, you are doing nothing but costing a business money. And cost centers are the first to be cut. You can sit there with your sense of self importance, thinking that the cleanliness and elegance of your code matters. But it just doesn't. Nobody cares. And the sooner you let go of thinking it matters the sooner you can focus your effort on what does. The reality is that when whatever old house of cards you're running fails for whatever reason, the business will switch to a vendor that covers 95% of the use case, while being much cheaper and not requiring FTE support. It will be a tiny bump in the road for the business, replacing this thing that you thought was a world beating make or break technology.
Micoloth 4y ago
That's amazing! Can you share more about what sector you are working in and what the software in question does?
WesolyKubeczek 4y ago
The problem that your product owner cannot see any value in replacing/understanding/modernizing that piece of software, but should it fail, the heads would roll, speaks of a bigger problem in your organization than an ancient piece of software. You have been able to put it in a container and it’s running, so unless the kernel itself changes drastically so old libc will just stop working, it’s going to be able to work unchanged for a decade more. But the communications problem between management layers is way bigger than that, and could probably bite in some other situation.
intrasight 4y ago
What would be an example of such a software company? I am always faced with this issue with non-software companies in industries where I've worked such as nuclear, defense, energy, and healthcare. At these places, I've confronted "hands-off" modules that are effectively black boxes of complex logic that has been vetted over decades, is written in C or Fortran, and nobody is allowed to modify. I can't imagine that situation existing in a software company.

alex-nt 4y ago

Fun story about the 3-4Y window, one of the execs at my company was having a Q&A, and he gave an example in another question a new set of components, saying that he expects them to be in use for the next 20Y. I asked why does he think he can keep the know-how and outsmart the competition (components were part of algo trading and other trading related things) for the next 20y with just this investment, and he just downplayed my question as an IT guy wanting more money/work. ¯\_(ツ)_/¯

giaour 4y ago

3-4 years is very short as far as software lifespans go. Software libraries that are 10-15 years old are commonplace in both open source and at FAANGs, and some industries practice "extreme longevity": any domain where you wouldn't be surprised to run into a mainframe is probably also running code with a 30 year+ lineage.

andrewf 4y ago
I don't think it's a coincidence that software lifetime has converged to the time it takes an initial stock grant to vest.