[95_JL_OK]

I'd tack onto the first point: obsolete technology everywhere. Worked in the public sector for a short while and the amount of outdated tech being used is astounding. Some of the solutions being discussed as "new" have been outdated for decades.

Having to deal with overwhelming bureaucracy in exchange for working on what everywhere else would be legacy systems really killed any desire to stay.

[nitrogen]

The most important aspect of any technology is that it works. In that regard, functioning "legacy" systems are ideal systems. The legacy bureaucracies are the problem.

Kind of like SpaceX popularizing rocket reuse, we should think of older code, languages, and frameworks as "battle tested", not "legacy". They should only be replaced if it's clear that essential maintenance is not possible, if a critical requirement isn't being met by the old system and will confidently be met by a new one, or if it can be demonstrated that a new system will save more money than improving the old one.

[95_JL_OK]

Absolutely... in the situation where the systems are actually legacy systems and not new installations or adoptions of obsolete technology. What I was trying to get at, and realize I expressed poorly, was that they are sometimes looking at implementing (today) things which are obsolete. That's what I meant by 'would be legacy anywhere else'.

This, I guess, would be a consequence of legacy bureaucracy, given that the people making the calls are not very aware of the new technologies and their advantages. A reluctance to adopt Python for example out of a distrust of FOSS comes to mind.

[ghaff]

But we should refactor it into a functional programming language with microservices running in containers because... resume-driven development.

I do agree that many organizations accumulate so much cruft they have trouble getting out of their own way. But the flip side of rewriting things for reasons isn't necessarily better.