47 ms·

As a systems admin of some 30 years, I have read this over and over, and even seen it firsthand. I think the real root cause of (at least in my case, the ones I

As a systems admin of some 30 years, I have read this over and over, and even seen it firsthand. I think the real root cause of (at least in my case, the ones I have seen) of this problem is management. Leaders do not want to spend now. Leaders do not want to make a progressive plan to keep up with technology and move ahead. It costs money, and is very difficult to talk to upper-upper management about. Telling the boss to tell his boss to spend money on something "that works now" is very difficult. Few want to invest in the future when it costs now and is working now (unless its the stock market).

mysterydip 6y ago
I think the problem is people think of hardware (and software) as a system, rather than a system-of-systems. It works now, because the exact combination of hardware, software, and peripherals available today works. Things you need to interface with use standards that your hardware is equipped with. As soon as that changes, your system needs to upgrade or change to continue functioning. Backwards compatibility only lasts so long, and is different for each interface (hardware and software).
- jrott 6y ago
  This is a huge part of the problem. The amount of risk that exists in legacy systems is actually pretty huge because of the amount of interdependencies that exist. It's the sort of thing that people who operate those systems know but that knowledge doesn't seem to spread beyond that.
  - WrtCdEvrydy 6y ago
    Trust me, I have had to do this myself :( Needed to increase the NodeJS version from 0.16 to 4.0 because a new shiny thing needed it. I knew it was a major version change but the dependencies didn't exist for the newer node versions... so rewrite something that isn't yours and maintain it forever... or do nothing.
tabtab 6y ago
It should be weighed like any non-trivial investment. Present an estimated yearly cost curve for keeping the system versus overhauling it: two curves. Upper managers will probably relate to that better than techno-speak. Typically a replacement system has a nearer-term spike in costs for development, but is cheaper in the longer run than keeping the old one, because the old one will need gradually more expensive duct-tape, chicken-wire, and harder-to-find technicians willing to support something obsolete. One advantage of the older system is that the costs are more predictable, because it probably works "good enough" at the time and will likely just gradually "degenerate". An overhauled system could be great or a grand failure. An exception is if a vendor stops supporting a key legacy component and there is not enough demand for 3rd-party tweakers to take up the slack. Similar can happen if a security hole is found in a key legacy component.
- WrtCdEvrydy 6y ago
  > Present an estimated yearly cost curve for keeping the system versus overhauling it That's the problem, most organizations can't track this. At a workplace, we replaced a legacy item with something new without doing this analysis... but after that, the move accelerated when it became aware making new features on "New vs Old" was a 2 hour vs 2 week endeavor. The new system covers 70% of the traffic and will slowly be going all the way to 100% of the traffic over the next 1-2 years.
- adrianN 6y ago
  Companies can't track costs that stem from systemic inefficiencies. Say your programmers still use CVS for version control and you want to convince management to switch to Git. The CVS server doesn't cost much, a git server wouldn't cost much either. There would be a large cost for changing all your tooling and processes that rely on the CVS model and in training your programmers to use the new system. Why would you do that? How do you quantify the benefits of atomic commits or simple branching?
  - nix23 6y ago
    That example is too simplistic, it's called legacy systems and not legacy software. If you upgrade your tool-chain you include git. Really no one is interested in upgrading 'just' git, make a package out of it (new compiler, new CI, new testing, new version controll..fuzz etc) call the project "sustainable nextgen tool-chain...short SuNeTuCha" and sell it to the management like that.

mysterydip 6y ago

I think the problem is people think of hardware (and software) as a system, rather than a system-of-systems. It works now, because the exact combination of hardware, software, and peripherals available today works. Things you need to interface with use standards that your hardware is equipped with. As soon as that changes, your system needs to upgrade or change to continue functioning. Backwards compatibility only lasts so long, and is different for each interface (hardware and software).

jrott 6y ago
This is a huge part of the problem. The amount of risk that exists in legacy systems is actually pretty huge because of the amount of interdependencies that exist. It's the sort of thing that people who operate those systems know but that knowledge doesn't seem to spread beyond that.
- WrtCdEvrydy 6y ago
  Trust me, I have had to do this myself :( Needed to increase the NodeJS version from 0.16 to 4.0 because a new shiny thing needed it. I knew it was a major version change but the dependencies didn't exist for the newer node versions... so rewrite something that isn't yours and maintain it forever... or do nothing.

tabtab 6y ago

It should be weighed like any non-trivial investment. Present an estimated yearly cost curve for keeping the system versus overhauling it: two curves. Upper managers will probably relate to that better than techno-speak. Typically a replacement system has a nearer-term spike in costs for development, but is cheaper in the longer run than keeping the old one, because the old one will need gradually more expensive duct-tape, chicken-wire, and harder-to-find technicians willing to support something obsolete. One advantage of the older system is that the costs are more predictable, because it probably works "good enough" at the time and will likely just gradually "degenerate". An overhauled system could be great or a grand failure. An exception is if a vendor stops supporting a key legacy component and there is not enough demand for 3rd-party tweakers to take up the slack. Similar can happen if a security hole is found in a key legacy component.

WrtCdEvrydy 6y ago
> Present an estimated yearly cost curve for keeping the system versus overhauling it That's the problem, most organizations can't track this. At a workplace, we replaced a legacy item with something new without doing this analysis... but after that, the move accelerated when it became aware making new features on "New vs Old" was a 2 hour vs 2 week endeavor. The new system covers 70% of the traffic and will slowly be going all the way to 100% of the traffic over the next 1-2 years.
adrianN 6y ago
Companies can't track costs that stem from systemic inefficiencies. Say your programmers still use CVS for version control and you want to convince management to switch to Git. The CVS server doesn't cost much, a git server wouldn't cost much either. There would be a large cost for changing all your tooling and processes that rely on the CVS model and in training your programmers to use the new system. Why would you do that? How do you quantify the benefits of atomic commits or simple branching?
- nix23 6y ago
  That example is too simplistic, it's called legacy systems and not legacy software. If you upgrade your tool-chain you include git. Really no one is interested in upgrading 'just' git, make a package out of it (new compiler, new CI, new testing, new version controll..fuzz etc) call the project "sustainable nextgen tool-chain...short SuNeTuCha" and sell it to the management like that.