3 ms·

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 man

by 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.
- collyw 6y ago
  > 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. When git seems to be by far the most used system on the market these days, isn't training any new hires in CVS going to be at least as much of a problem? I used it in my first job in 2003 / 2004, but I can't remember how to use it now. Do companies with legacy code tend to keep staff around for longer?

by tabtab 6y ago

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.
collyw 6y ago
> 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. When git seems to be by far the most used system on the market these days, isn't training any new hires in CVS going to be at least as much of a problem? I used it in my first job in 2003 / 2004, but I can't remember how to use it now. Do companies with legacy code tend to keep staff around for longer?