Hacker News Reader

Comment by readingnews | Hacker News Reader

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).

View on HN

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).

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.

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.

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.

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?

> 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?

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.

> 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.

Reply on news.ycombinator.com