US CIO/CTO: Idea of Hiring COBOL Coders Laughable 265
theodp writes "If you're a COBOL programmer, you're apparently persona non grata in the eyes of the nation's Chief Information and Chief Technology Officers. Discussing new government technology initiatives at the TechCrunch Disrupt Conference, Federal CIO Steven VanRoekel quipped, 'I'm recruiting COBOL developers, any out there?,' sending Federal CTO Todd Park into fits of laughter (video). Lest anyone think he was serious about hiring the old fogies, VanRoekel added: 'Trust me, we still have it in the Federal government, which is quite, quite scary.' So what are VanRoekel and Park looking for? 'Bad a** innovators — the baddest a** of the bad a**es out there,' Park explained (video), 'to design, create, and kick a** for America.' Within 24 hours of VanRoekel's and Park's announcement, 600 people had applied to be Presidential Innovation Fellows."
Re:Good luck with that... (Score:5, Interesting)
You must not have a manager who cares about building your career, or maybe you aren't sufficiently motivated to move up. Might want to find a new boss or an injection of testosterone to get the juices flowing.
This is not something even a good boss can really solve for an employee. The fundamental issue, in my mind, is that the people who write, interpret, and enforce the bureaucracy's rules, will get beaten up only if the problem they're trying to prevent actually occurs. For example, a Section 508 compliance officer will get beaten up if they let someone buy a code analyzer that's not easily usable by someone who's color blind. Or an information assurance officer will get beaten up if there was any risk that a supposed vulnerability (even a false positive) went unpatched.
But those people get in no trouble if they (a) bring projects to their knees for lack of needed hardware/software, or (b) add weeks of delay to a project because they had a false-positive vulnerability report, which they "just to play it safe" take the project's source control server offline until the project members can prove that the vulnerability is in fact a false positive.
Working for the federal government can be awesome. I.e., keeping your fellow citizens safe in various ways is far more satisfying than is padding some CEO's excessive bonus. But between this bureaucratic crap, and having every Republican candidate for public office slander you to score political points, I'd say it's a wash at best.
Re:COBOL might be an awful, outdated language (Score:2, Interesting)
I must say if you cant get them to change then your doing it wrong, where I work we are in the middle of a 10 year project to move from COBOL batch processes to all .NET with no batch processes. The first steps are done, there is no more COBOL or mainframe its all in .NET running on 10 clustered servers (4 app servers, 2 DB servers, 4 web servers) that act just like the old system only with a lot more redundancy built in. The next steps are to slowly move away from the batch system and move to an interactive system with access given direct to the customers who need access to it. Oh and BTW I do work for a government agency so it can be done it just takes some pushing and moving slowly to get there.
Re:Of course they are not in the TechCrunch audien (Score:5, Interesting)
Except when some dumbass kid writes that older coders can get "obscenely high-paid" work of any kind! In the tech industry seeing ANYBODY over 50 working (even on a short term contract) is a rarity and probably a fluke! And seeing a 60+ COBOL programmer implies that you are hallucinating!
Re:I've seen it all. (Score:4, Interesting)
I wish I had COBOL for Linux
Looks like it's still a work in progress, but: http://www.opencobol.org/ [opencobol.org]
Joke all you like (Score:5, Interesting)
You people can joke all you like about old languages.. I'm getting paid to use, maintain and write FORTRAN code.
In the past, I have written FOSS in FORTRAN and put it in the public domain. People still download it on a weekly basis.
FORTRAN has gone through 10 updates and code that was written on cardboard in the sixties can work together with OO code from last week.
FORTRAN is the back-end for the NumPy and SciPy numerical libraries. Python is just a fancy way of writing FORTRAN.
And, no, I'm not an old fart (yet), but I can chase you off my lawn nevertheless.
Now go away, or I shall taunt you a second time...
Re:a**? (Score:2, Interesting)
It's many years ago I did that, and pointers were only rarely needed in COBOL programs, but it was something like this:
SET ADDRESS OF B TO A
SET ADDRESS OF C TO B
B and C had to be defined with a 77 level in the linkage section, I think.
Re:Of course they are not in the TechCrunch audien (Score:3, Interesting)
Re:I agree with this sentiment (Score:5, Interesting)
I'm curious as to what makes COBOL the right tool for data processing tasks.
I was under the impression that much of the reason it was still around is generally because there are existing large projects already written in it, and it is generally deemed to expensive to try to convert to some more modern language. You make it sound like there is more to it than just that (although surely it plays a part).
What makes it a better language than say Java or Python for data processing tasks? If one chooses to use those languages in a more purely procedural style (rather than an object oriented style) would they not produce similarly straightforward code, but with the advantage of having a much larger pool of developers?
That's a fair question. I'll try to give a quick answer without starting a language flame war. :)
First, to be fair, good programmers can do just about anything with any language. We've done remarkable things though the decades with very little. Now that computers are relatively infinite in capability, even bad programmers have a shot at doing anything with any language. So it doesn't matter as much anymore.
But as an IBM RPG programmer, which has similar attributes as COBOL, the reasons are high speed transaction processing with language and even hardware support for binary decimal data type and direct disk IO, not limited to SQL for database IO. Programs are written with typed variables and compiled. Efficiency used to be paramount to accomplish what needed to be done, and it still is highly efficient.
The IBM mainframes and midranges these programs run on can be smaller but scale to very, very large environments that are very secure. Java also runs on these systems and we write systems with it and is used extensively, but generally not for the hardcore data processing jobs.
When something is processed, be it a screen, something from a web page, a record from an input file, etc., we usually hit several files in validating and updating info, on a transaction by transaction basis. It can be emulated with extremely complex SQL statements, I've seen some of them, but it takes quite a bit of engineering to attempt to do all the IO we routinely do for transactions.
The IBM midrange (i OS) and mainframe operating systems are also a big part of the success of RPG and COBOL, respectively.
I've always said that if i OS were written today by an OSS team you guys would think it was the second coming of operating systems.