My first piece of advice was to ditch the current system and revert to the old. This had been purposefully sabotaged by the suppliers of the new system. The only way out was then to go forward and this nearly killed the company.
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.
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.
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.
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.
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.
Especially not if there is financial information involved.
Personally, I really, really don't like Visual Basic. I don't even claim to have anything resembling a rational reason for this attitude. It's deeply ingrained prejudice. And if I have a reasonable alternative to touching VB code, I'll take it gladly.
But I've had to touch a few VBA/Excel based "applications" over the last year or two, and I did it. It was no fun at all, but it was still better than rebuilding those things from scratch. In one case, we replaced an Excel sheet crawling with VBA by a PivotTable which does the same job, is more maintainable, the file is a lot smaller and it appears to run slightly faster.
There is also a part of me that loves picking up some old code written by somebody who has long since left the company, possibly to solve a problem I do not fully comprehend, and fix some obscure bug or add some minor feature. So far, I'll admit I was quite lucky in that those programs I had to touch were reasonably well written, or at least readable and structured in a sanity-preserving way. But still, it's fun, in a way, and the "dirtier", the funnier; at least as long I have a clearly defined task and get to walk away from it when I'm done.
Using the hot new toy that all the cool kinds are using is probably fun, too. But working on a 10-20 year old application that only a handful of people have ever touched, has an appeal that outweighs the distinct lack of sex appeal. Plus, you get to tell some interesting stories about the things you've seen. =)
Goto considered evil is folk law when it comes down to it, I think it's almost universally believed but the fact that I don't immediately think of a crystal clear quantitative result to underpin the view that jumps in code are bad is telling.
I think that some of what is going on here is economics though, coding in the new way gives a good line of patter for the next gig, and we all need to think about the next gig.
Of course, there's a problem when sometimes you want to stray from the patterns encouraged by the language, but it doesn't provide adequate means to do so.
But why limit yourself to GO TO to fixed places??? Fortran IV also let you GO TO an arbitrary statement that would only be chosen at run-time "assigned goto".
Fortran 77 still has that capability but you can limit it to specifically selected statements and it won't GO TO outside of the current unit (a concept Fortran IV lacked.)
Dijkstra's remarks were contemporary of Fortran IV.
> ...a programmer's personal preference is more important to getting results than the language or paradigm itself. In other-words, if a programmer can work with the tools and languages that he or she most prefers, then productivity and quality may be much higher than from passing down edicts based on a blanket choice of tool, language, or paradigm.
This backs up a lot of what I've seen over the years and I consider it wasteful in the extreme. Maintainable, functional applications are constantly thrown out because programmers don't want to use things they consider "dirty". "Eww, I don't want to go anywhere near that. It's (procedural|PHP|got 'goto' statements|VBA|not the cool thing that everyone's talking about)."
Yeah, but this thing works just fine as it is. Your job is to improve it without making it worse for the next person, not Reactify it until you've exhausted somebody else's supply of money on a hunt for unicorns.