If this were a data entry tool, I'd agree on the TUI part. It's a data processing tool and a bottleneck. There have been several replacement efforts, all canceled (your tax payer dollars at work, these were government contracts long before my time on the system). It should be 1-3 networked services (common data store, different tasks making 3 services a logical outcome rather than 1 service doing too many things but it's small regardless so either way is reasonable).

The customers in this case feared change too much to accept anything that wasn't exactly what it was replacing. Which meant that there was no point in doing the work.

> The customers in this case feared change too much to accept anything that wasn't exactly what it was replacing.

Now, the interesting question is, who gave the pushback. Particularly in government, change in the "status quo" is feared because it would force the really old ones to deviate from a routine they have been living for decades - they'd have to basically re-learn their jobs, all for a few years before retirement. Others don't want any kind of improvement because then the young people, used to modern technology, would go and run circles around them regarding productivity, which would impact the "oldtimer" careers negatively.

And in some rare high-stakes cases, the system is mission critical and any kind of deviation from the previous way of working can literally send people to prison or cause massive monetary damage. Here, everyone wants to keep the status quo in order to not awaken the beast, and the incentive grows really powerful when it's some old mainframe system with tons of undocumented implicit assumptions and edge case covers.

Government work in my experience is a whole bunch of negative incentives from all levels thrown into a blender.

Reportedly close to 100% turnover in the actual userbase (versus the paying part of the government) every 2-3 years. So it's not about deviating from routine, but those users aren't given a voice in the change efforts.

This is an issue with the program management which is very common in government. They are too change averse even when change is necessary (to satisfy their own requirements in this case, the DOS box can't connect to the network but they want the system on the network).

> particularly if your userbase often has literally decades worth of muscle memory

My experience from informally inquiries shows that users value fast TUIs regardless of the experience they amounted. Even the young mainframe and (rarer) Clipper users I talk to report preferring these systems over newer, web-based ones.

I worked in the travel industry, and the old TUI was much more efficient at several tasks than any GUI that we could provide.

As developers we should show some sympathy, but some of my co workers didn't see it that way. They complained about the old TUI, while they themselves preferred using a terminal for git and other tools that actually have most of the functionality that they need in a GUI

> As developers we should show some sympathy, but some of my co workers didn't see it that way. They complained about the old TUI, while they themselves preferred using a terminal for git and other tools that actually have most of the functionality that they need in a GUI

At least for git, I prefer a terminal as well. git is easy enough to shoot yourself in the foot when you're using it in a terminal, but git GUIs tend to abstract away so much for anything more complex than "git commit/push/pull" that it's even easier, and way harder to recover from.

I prefer git GUIs. Never used git in a terminal.