Bah!
Maybe a little less focusing on replacing Cobol with the Language Du Jour and a bit more on the Lost Art of Systems Analysis would pull the trick off?
Couple of years ago I had to listen to some Armed Forces bigwig telling America that the reason soldiers were not being paid was "old-fashioned Cobol systems" when in reality the (four different) Cobol systems in use by each branch of the armed forces were working fine. The problems started when they threw out the Cobol and introduced a new "integrated" system that was supposedly All Things To All Forces but in fact turned out to be No Thing For Any Forces.
The rules haven't changed just because the jargon has:
1) There must be a better way of doing it
2) There was a damn good reason for doing it the way it is now
3) Leave it the fuck alone - until you *understand* #1 and #2.
I'm currently helping support a large application which had a new internet-enabled suite added on. Underlying design assumption: All the data needed by the new parts will be there when queried. This data is from a periodic asynchronous load set provided by an independent source over which we have no authority or control. What happens when the data *isn't* there? Headless Chicken Dancing and the dreaded Teams Meetings.
When did programmers-sorry-software architects stop working from "what happens when this isn't true?"
If I had provided anything like this as a trainee back before micro computers I'd have had my fingers broken by the Chief programmer.
Biting the hand that feeds IT
