US CIO/CTO: Idea of Hiring COBOL Coders Laughable
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."
Another example in a fine history of mindless government bigger-dick wagging. Pretty close to being up there with: "Mission Accomplished" and "Bring 'Em On".
We know where leadership by an anti-intellectual "strongman" who scapegoats minorities and likes boisterous rallies goes
You mean ass. No need for silly regular expressions.
I'm recruiting COBOL developers, any out there?
They are out doing obscenely high-paid consultant and maintenance work for banks, insurance companies, etc.
I had planned on doing the same thing with C development, but those damn meddling Apple kids have made C popular again.
Schroedinger's Brexit: The UK is both in and out of the EU at the same time!
I'm sorry to re-post the same comment from another story, but in this case it seems very apropos:
Agreed. As someone who's worked for the U.S. federal government, the amount of effort required to comply with various directives, even to accomplish the most basic of tasks, is maddening.
For example, suppose you needed to order some laptops for your developers, and some compilers as well. Private sector: 4 hours to shop around, and you'd have the order fulfilled in about 3 weeks. Most of that delay would be for custom builds of the laptops by Dell, HP, etc.
In the government: 20 man-hours gathering competitive bids from 3 vendors who agree to work under the pricing schedule your agency requires. 4 man-hours / 2 calendar days ensuring the order complies with Clinger-Cohen and Section 508 regulations. 20 man-hours / 2 calendar weeks getting permission to place the order from one approving authority. Another month going back-and-forth with another approving authority. Then the order gets placed.
The opportunity costs and labor costs associated with the effort and delays in getting s**t done in the federal government is mind-numbing. When feds get bashed for having, in some cases, more costly compensation packages than the private sector, there's one factor that rarely comes up in conversation: any competent software developer will demand a pay premium in exchange for putting up with this soul-sucking crap on a daily basis.
Park seems to like a**es
Seriously... if there were a new world and you can get on a ship and go.... and never come back... how many would just do it.
that's an extreme reaction but it's just one stupid thing after another... I just want to go...
I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
But I'd hate to be the poor souls stuck with porting (and, god help them ,refactoring) forty+ years of working COBOL code . Talk about a thankless task - if you get it right, noone will know anything happened, and if you get it wrong, you'll never hear the end of it.
Are you a bad enough dude to innovate the President?
Actually, I learned a lot from doing COBOL work. But it's clear that experience doesn't count. Instead employers do buzzword search on resumes for the latest hip technology or alphabet soup "certifications".
It wouldn't be quite so bad if the industry didn't choose to adopt one labor-intensive technology after another. Most of the current programming fads don't scale up for large projects (>100k SLOC) any better than a lot of the stuff we used 20-30 years ago. Too much training and education, and then too many tools, focus on the individual, rather than on the team of developers/maintainers for long-lived applications. But I suspect a lot of senior managers think that large systems are irrelevant; everything will be a 1000 line "app".
This is a problem that is -independent- of the inefficiencies implicit in working for the government (as either an employee or a contractor.)
For what it's worth, I have always insisted that any programmer/developer that I had any influence over hiring must have demonstrated competence in more than 1 programming language/development approach. And "C/C++" didn't count as 2 languages (both because so much of C++ is bad C with an OOP veneer, and because a lot of core concepts, including bad habits, are shared between the two languages.)
Hey Karmashock, when does that ship sail?
We blazed a trail with COBOL. Other languages may be better, but COBOL was the early language that made computers useful to a large number of business's and governments. The reason there is so much of it, is that it works.
~S
There, I said it.
The US CIO/CTO is a brogrammer.
Dilbert RSS feed
It may be hard to maintain, but COBOL works and it works without too many bugs. COBOL is usually replaced with web GUIs which are prone to exploits and require a lot more processing power. They do look pretty though.
You left out "And get off my lawn!"
Most good coders are not going to be hugely interested in whether they are a GS-12 or if they have a shot at moving to GS-13. They want decent pay, good working conditions and colleagues, and interesting projects.
There are good people (and great bosses) in the federal government. The problem is that there is also a huge amount of dead weight: petty people building their personal little empires and playing pathetic office politics. The "iron rule of bureaucracy" will not be denied - even if you are lucky enough to work in a super organization, don't worry: its soul will eventually be sucked out by bureaucrats interested only in extending the bureaucracy.
This is why government organizations should be kept to a minimum. In industry, when the deadwood has accumulated, either it gets cleared out or the company dies. In government, you just get a funding increase.
Enjoy life! This is not a dress rehearsal.
I'm sorry, but if you're developing in anything other than machine language, you're really leaving performance on the table. No namby pamby assembly, no wishy washy COBOL, no effete C, and definitely none of those worse options. Write it in machine language or know that you're an incompetent hack.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
I always remember the following Dilbert strip from 1997 when I hear the words Cobol programmer:
http://dilbert.com/strips/comic/1997-11-04/
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!
I killed da wabbit -Elmer Fudd
With most new ECMs you simply alter the pattern coming from the crank position sensor real time into a slightly different pattern that gives you the spark you want. It also allows you to raise the rev-limiter as well. The ECM calculates the RPM tooth to tooth, so if it thinks the engine is @ 7000 RPM when its not scheduling spark, and after fuel injection has started (sequences are start angle + time and will not be cut short) you will be fine! There's only certain spots a in a rev where it has to 'think' its going the right speed so you have quite a window to trick it into thinking its in a different position in order to get the end result you desire.
An AVR @ 16 Mhz can easily simulate a 60 tooth pattern at 12000 RPM, That's only a 12Khz output freq, that's nothing, and you still have enough clock cycles to modify the MAP sensor too. The best part is the stock ECM (and dealer) is none the wiser:)
I called my source code The_ECManipulator
Cheers
What's so scary about running COBOL? If there are systems written in COBOL that are doing what they need to do, why is that scary? You could spend millions of dollars rewriting the system in something more kick ass (not sure what's considered kick ass enough for the US Government - Java? .Net? Ruby?) and then you end up with million dollar system that does the exact same thing as the system before, except for the inevitable bugs that creep into any large software project.
Or you can start from scratch, and write new specs for the system and build a system with new kick ass functionality, then you end up spending millions getting the stakeholders together to write the specs, then millions more actually writing the new kick ass software, and decade later, it's been deployed with all of the major bugs worked out (or worked around). Except that whatever kick ass software you chose to write it in is no longer kick ass, so you need to start over again with something more kick ass.
I worked at a company like that once - the new CEO decided that the old system written in C was no longer kick ass enough, so he decreed that it had to be written in something modern and kick ass -- in this case, it was Visual Basic that was deemed kick ass enough for it. So the company spent years specing and rewriting a system to be deployed across 1500 remote locations. In testing, they found that their VSAT communications system couldn't provide enough bandwidth and adequate latency to each location, so they embarked upon an expensive project to replace all of the VSAT connections with high bandwidth wired connections (this predated DSL and other cheap ways to get fast ethernet connections). In the meantime, the core developers of the original project saw the writing on the wall and left the company to start their own consulting company - they made a killing maintaining the original system while the company focused on building the replacement.
5 years later, this 2 year project still wasn't ready for deployment, the company got bought out before the project ever got off the ground, and I'm sure the CEO got a healthy bonus for his "vision".
I wish I had COBOL for Linux
Looks like it's still a work in progress, but: http://www.opencobol.org/
well, its more a case of "choose the right tool". COBOL is the right tool for data processing tasks - stuff like running payroll or reconciling credit card transactions. Its not sexy or cool, but it works, and for the most part works so well we're still using code written back in the 70s.
Idiots will take that reliability and stability as a sign that it's a no good, legacy language that no-one wants anymore. They are idiots who will replace it with a multi-million dollar project rewriting it in whatever cool tech is du jour, that would probably be a HTML5 'interactive' website today, but in previous years either enterprise java beans, C# and biztalk, CORBA objects, or web services. So who hired these numpties into a position where their ignorance can fuck up the real world?
Where the hell do you work? Wait, I can guess the answer, Sillicon Valley? I'm right, aren't I? So, the point being that just because you don't see any 60+ COBOL guys around, doesn't mean they aren't. You know all those legacy systems... the ones that have more up time than your life span? The ones that were installed before you were walking, and haven't moved since? Because I DO. So does your local government office, and your local bank, and your local CC processor. Did you know that your water company probably still uses and old AS400 for account management? Because I do. Did you know that every street light in the greater Portland (OR) area is tied to a positively ancient server running some obscure COBOL? I do. Do you know the guy that gets paid to keep that server running, despite 3 separate efforts over the years (totaling many millions of dollars) to replace it? I do. Want to know what he gets paid to be the ONLY person in the state with access to that machine? I'll bet you wouldn't believe me.
What you kids in SV think constitutes the computer world... well, lets just say that you are standing in a valley, and you can't see the rest of the world from there.
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...
These guys reminded me of the web developer in this old IBM commercial. Yeah man, let's put flaming skulls on there, it'll be kick ass! If either of those two guys looked at source code they'd probably have an aneurysm.
-- I ignore anonymous replies to my comments and postings.
I just hired two programmers, one is 59 and one is 61. I'm sure it's due to the tech: C++ / VB6 and some .NET, but I needed developers to maintain a system we won a contract to support. Perhaps I'm odd ... but age never factors into my hiring decisions.
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.
I've never understood the reasoning behind not wanting to hire old guys. I can understand why you wouldn't want to hire a grumpy, inflexible old veteran who insists on recoding everything into COBOL because he has no other skills. But those are a minority as far as I can tell. I know several older DBA's, system architects, designers with even nation-wide fame: they get hired every day by the *smart* companies that want to ship product.
Therefore, by the (faulty) logic you're using, you're just a cow with a keyboard - osu-neko (2604)
Want to know what he gets paid to be the ONLY person in the state with access to that machine?
Coffee and donuts?
Thanks.
You're welcome?
Objective-C is to C as Javascript is to Java. Thanks.
Javascript is an extension of Java?
The Tao of math: The numbers you can count are not the real numbers.
Good for you. Unfortunately, this attitude is not pervasive. At 45 I don't consider myself old yet when I see posts from 20somethings stating you don't see anyone older than 50, it's disheartening. I have an engineering background and approach software development as an engineering activity. I would hope companies want to hire disciplined, productive developers but the norm seems to be to hire based on an acronym alphabet soup. During interviews, it's rare to hear questions about your development approach, it's often about "how many years of XYZ do you have?" it's not the programming languages that are important or the brand of datavase server, it should be "how good of an engineer am I hiring." Also, equally unfortunate is the prefiltering HR departments do on resumes, older engineers often don't even get an interview. I've removed about half of my experience from my resume so it doesn't go so far back - age is easy to deduce when you experience going back to 80s.
I'm 45+, you insensitive clod(s)!
AFAIK, I've only done COBOL once, for a diesel sequencer IIRC. Most of the rest has been c and c++