Politics of IT in the U.S. government

http://www.itworld.com/article/3103585/government-it/politics-blamed-for-feds-reliance-on-old-it.html

Hi all,

In the preceding article, put away all the politics: That's not the
subject of my email.

At first I almost vomited when reading this sentence:

================================================
The Social Security Administration, for instance, has more than 60
million lines of Cobol,
================================================

My first thought: Cobol? Are you kidding? I thought I'd gotten done
with that in 1985!

And then a part of my mind said "sysvinit? Are you kidding? Etc.

So I started thinking about it. Except for the lack of local variables
(and this is a huge lack, in my opinion), Cobol was a pretty decent
language. When it came to letters and numbers and data, it got the job
done. For its time, it was pretty portable: You just changed the
Environment Division. And it wasn't tough to learn or write, always
assuming you were a fast, prolific touch typist.

I looked at the "new languages." Most of their claims to fame were GUI
Pretty, which doesn't matter when you're calculating peoples' checks.
Then there's OOP. My opinion: OOP didn't achieve our expectations for
it, it's often misused, it's vastly misunderstood.

So what, rewrite the Cobol in C? I don't think anyone wants all the
pointers. C++? What a mess that would be. Maybe one of the Microsoft
languages. Or maybe not. Python? Meh. The only real problems with Cobol
is it has no local variables, and few people will ever learn it.

Gary from my LUG told me something that stuck with me forever. His
applications were all logic, no presentation. They operated through a
socket via a very simple API or Domain Specific Language. A front end
could then be written to that same socket, the two could talk to each
other. So Gary could focus exclusively on data processing, the front
end guy could focus exclusively on pretty, and they meet at that one
little socket with a thin, simple interface. No MVC nonsense, no having
an application be part of a window (talk about the tail wagging the
dog), no volleyball code, just a straight single-bolt relationship.

I made a program called UMENU. It's just a keyboard driven menu program
without the need to press Enter, and it has Prompted Argument
Substitution so it can stop and prompt me for arguments to the program
it's about to run. Because I have UMENU, I can write a program whose
entire interface is its arguments: A program that would be
unrememberable and undiscoverable in and of itself. But then I operate
that program with UMENU, and BANG, I converted the program to an easy,
menu driven application.

If the government needs pretty-gui for the untrainable minimum
wage workers they hire, they could make a command driven front end to
the Cobol that presents the Cobol program as a pretty GUI. A lot better
to leave the core as Cobol rather than risk some boze intermixing
algorithm and presentation, and that happens all the time.

Hey, I'm not saying we should go old for old's sake. I'm just saying
sometimes there are good reasons not to rewrite old code that's still
functional. And, of course, I'm also saying we shouldn't go new for
new's sake.

I think this is ontopic at DNG because making interfaces few and thin
is a philosophy.

SteveT

Steve Litt
August 2016 featured book: Manager's Guide to Technical Troubleshooting
Brand new, second edition
http://www.troubleshooters.com/mgr