A previous employer had an application that was very successful (from a business perspective) because it wasn't flexible - they did a lot of acquisitions (one a month at one stage) and if there were any questions around their internal systems they got this application inflicted on them. At first I was horrified (it was ancient, user hostile, completely inflexible) but I actually saw that it worked - the companies being acquired were all in the same industry and their core processes were all pretty much identical (even if the terminology was all different) - so they could all adapt to the new application and it actually ended up working pretty well.

More "modern" flexible applications ended up having multi-month/multi-year "implementation" phases as teams tried to change their new application to their existing processes when it was actually easier to standardise the processes around a fixed application.

Airline companies typically have ancient stuff running but from a productivity point of view that old stuff beats the 'new' stuff hands down. It just works, has 0 overhead in terms of eye candy and so on. Ok, you can't play minecraft or solitaire on those machines but that's probably a benefit.

Also, on those old systems running IBM RPG and other "green-screen" UIs, it's really impressive how fast users can navigate the system via keyboard commands when they are forced to not have a mouse.

I remember working in a bank in late 90s and while GUI apps were starting to replace the 3270s, completely non-technical "lifers" had just fully assimilated the old mainframe app.

Getting an account balance for example was a "Question 8" if I remember right, that is, the PF8 key on the keyboard. Routine banking operations were maybe a couple dozen keystrokes and mostly all the same pattern but different function key with paper overlays taped to keyboards to "name" the PF keys.

It wasn't pretty and the learning slope was steep but the same people who wrote their emails in Lotus Notes in All Caps and scanned word doc printouts into new word docs had no problem memorizing all the obscure operations they had to do every day.

One person I knew had a particular system down so well that they could fill the type-ahead buffer for several screens ahead of the mainframes response, the screens flashed by too fast to read.

That's amazing that they purposefully sabotaged it! How did they go about doing so?

Well, given that it is much easier to destroy a system than it is to build one in the first place the actual method doesn't really matter much. Take your pick. How would you sabotage a system?

In this case they canceled the contracts on a bunch of facilities that were crucial to operating the old system and that would take a very long time to set up again.

But the whole idea of a non-revertible change-over without at least a period of having the old system on stand-by just in case all by itself is totally reprehensible, especially since their testing regime was comprised mostly of 'let's go live and see if it works'. Of course they didn't mention that little fact beforehand, only afterwards was it made clear that any attempt to move back to the old setup was going to be fruitless because they'd 'closed the door behind them'.

I suspect that they knew full well the new system wouldn't work properly and that if a revert would have been done this would likely trigger some serious backlash so by saddling the client up with the new system and making sure they could not go back they forced them to accept the new situation no matter what. Job security by any means.

Only that part ended up not working.

I've never seen a clusterfuck like this before and I really hope I won't ever see one again.

"How would you sabotage a system?"

Just to provide another example, "write a stub prototype of the new system, discover $CRAPPY_ORM in my new hotness language doesn't like a couple of the database constructs, migrate production database to work better with the prototype, new system fails to generate some data the old system needed (history, audit logs, tons of options here)". Back migration now effectively impossible.

Let's imagine that YOU were doing the rewrite, and for all the best reasons. Totally different situation. Would you write your code to continue saving some bizarre unnecessary data in the database, or would you get the job done with a sensible scheme? As for the other comment, were they supposed to continue renting out completely unused facilities in case someone came along who thought the old system was better?

There are proper ways of doing this: you run the old system in parallel with the new system and you outfit both systems in such a way that all writes are done on both systems. That way the DBs stay in sync.

So you won't have to 'write your code to continue saving some bizarre unnecessary data in the database' and you can have your 'sensible scheme'. It just takes a little bit more care and planning.

> As for the other comment, were they supposed to continue renting out completely unused facilities in case someone came along who thought the old system was better?

They ended up renting a good part of those facilities anyway, the problem was not the money but the fact that certain comms lines had been torn up.

Playing cowboy with critical company data is not a winning strategy.

There is absolutely no reason why you couldn't pair those strategies ;)

Especially not if there is financial information involved.