

COBOL: Everywhere and Nowhere - bdfh42
http://www.codinghorror.com/blog/archives/001294.html

======
AndrewO
I've never met a COBOL programmer. The only times I've seen actual COBOL code
have been examples to show how inscrutable it can be (like the example in the
article). I haven't seen any open source software written in COBOL, although
I'm sure there has to be something. Yet, I know COBOLers are out there.

Given the fact that COBOL refuses to die and not for lack of other options,
I've always assumed there's something that kept these guys going. I used to
think it was just hard-headedness ("Haven't these guys heard of Python or Ruby
or even like Java or .Net or something?!?!"), but age and experience have lead
me to believe that it probably has something to do with the size of the
paycheck.

So I'd really like to know:

Do COBOLers have a community of any sort?

Where do they go for help?

Do they read HN or proggit (or do they have their own portals that only run on
green screens)?

What keeps them going (and do they actually despise their language but just
suck it up)?

Are they locked away in the dungeons of enterprise IT departments (or are they
more like the wizards in a tower)?

Is there some sort of annual conference where they all meet and dance in front
of a bonfire (lit from the heat of their mainframes) and sacrifice young
virginal (pure? dynamic?) OO or functional languages to keep their own alive?

~~~
ryansloan
I worked as a COBOL programmer for two years (well, technically I did 2 summer
internships and two short winter stints) so I have a little insight into the
"community."

I worked at a (successful) company that develops banking software and
processes bank data. The majority of our data processing and operations
codebase was written in COBOL, running on some Unisys mainframes. There is a
growing population of .NET developers on the team, but for the most part the
cube farm is full of COBOL programmers. In general they don't read HN, use
StackOverflow, or any other online community that I'm aware of. For the most
part, when they need support they ask one of the local dinosaurs. I have
noticed that most of them don't use their career to define themselves like a
lot of "modern" programmers (myself included) do. I think it's more of a 9-5
for them.

And they don't seem to hate COBOL, either. In fact, a lot of them like it. I
think part of the reason is that it's one of the first languages they were
exposed to, and one of the first mainframe-based languages that "made sense."

It really is everywhere (although 80% seems high), but you don't usually find
it in any of the glamorized jobs. It's heavily used in the banking,
healthcare, insurance, and payroll industries.

I'm still working for the same company, but I'm doing .NET stuff now.

~~~
AndrewO
In your opinion, why do you think they stay away from HN or Stack Overflow? Is
it just that there's nothing there for them specifically or would you say that
they're (on average) less interested in the wider programming ecosystem?

~~~
wooby
I'm not sure this kind of entrenchment is endemic of COBOL programmers
specifically. I knew plenty of people in college who, once they knew Java,
were perfectly content with their ability to program, and will probably be
happily employed for the foreseeable future. I think it just boils down to the
difference between the 9am-5pm'ers and the 5pm-9am'ers.

------
michael_dorfman
I think Jeff answers his own question when he refers to _my entire so-called
"professional" programming career_.

The fact is, there are a lot of professional programmers doing a lot of work
that don't mix in the same circles as Jeff. The fact that they don't read his
blog, or post to StackOverflow doesn't mean they aren't out there.

~~~
gdp
The sentence after that one says: "That probably says more about my isolation
as a programmer than anything else".

The point is valid, if only to speak of an interesting separation and the
generally low-visibility of COBOL in parts of the programming industry.

I can't say I've met anyone who is still actively writing or maintaining COBOL
code either. I know a few people who wrote COBOL at the start of their
careers, but who have since transitioned into other things.

So I think the validity of the observation stands. A quick straw poll of my
colleagues within earshot (yes, I'm reading HN at work) suggests that none of
them know any active COBOL programmers either. This is from a group of people
from very junior to very senior, with a range of about 1 - 20 years of
commercial programming experience.

~~~
michael_dorfman
_So I think the validity of the observation stands_

Which observation? That the COBOL-type programmers (and we can add in RPG, and
other non-sexy languages as well) are isolated from the rest of the industry?
Sure. But in-house developers of serious, back-end-heavy apps have always been
isolated-- including from each other.

~~~
gdp
No, that the reported popularity of COBOL is at odds with the anecdotal
evidence.

~~~
michael_dorfman
I think if you started calling around to banks, hospitals, transport
companies, oil companies, old-school manufacturing facilities, etc., and
started inquiring about their existing codebases, you'd get a whole other set
of anecdotes.

~~~
gdp
And that would be an interesting thing to see a blog post about too!

------
jgfoot
Vernor Vinge's fiction introduced the concept of the "programmer
archaeologist," which seems appropriate here. He predicted that in the distant
future, the skill of programming will have entirely shifted from writing new
code (everything you need has already been written) to reading and curating
old code. We may be there with COBOL already. _Understanding_ COBOL might be
more important than _writing_ COBOL, so the newest variants of COBOL (like
.NET) are _less_ relevant than the old stuff.

------
pauljonas
Lots of COBOL still in existence.

If you use a credit/charge card, make an airline reservation, have an
insurance claim adjudicated, pay a utility bill, etc.… odds are an old-school
COBOL application (with a DB2 database or even more archaic IMS hierarchical
system on the backend) is going to process that transaction. Sure, a snazzy
web frontend might be in place now, but in the guts is buried business logic
reduced and offshored staff no longer possess, and life lingers, only measured
in half-life units now…

Most corporate COBOL (as this is the province of Fortune 500 firms)
application support and development is handled by offshore vendors, primarily
in Asian and Indian locales, with facilities here in the states to hold non-
immigrant visa programmers.

COBOL knowledge (and a lot of the details are buried in the platform it runs
on — in my experience, mostly IBM mainframes, though I started on Burroughs
hardware) is still in a pre-internet age, and college textbooks and three ring
bound together 8 1/2 by 11 pages serve as instructional aids, along with
experience.

A lot of corporate outlets have engaged in boondoggles to replace the COBOL,
but a good deal of these efforts have been epic fail:

* …lot less business knowledge handicaps

* …likely to whiz-bang consultant firms with their own lock-in proprietary systems that woefully underestimate effort to decompose and recompose legacy system…

* …the systems running have been optimized over the years, and they're tied to existing data center operations, which in many cases, are run by IBM. It may seem incredulous today, but even in the 90s, the mainframe systems ran circles around PC and web solutions, especially the "solutions" vendors were offering at the time.

------
Tichy
I think 80% of active code being COBOL can not possibly be true. Computer use
and "active code" have probably grown exponentially over the years, and the
new stuff hasn't been in COBOL for a long time.

~~~
dimitar
Thats a Gartner Group claim from 1997. I wonder what would the share be now
according to them.

~~~
Tichy
For 1997 I can believe it - thanks for the info!

------
bdfh42
Just the other week I wrote a couple of .NET classes to read 'native' COBOL
Indexed Sequential files from a brand new package installation at one of my
client's sites. This package is still in active development in COBOL because
the code is just about unchanged across multiple platforms - (Open VMS and
Windows are both very similar from a COBOL point of view)

------
sethg
Back during my year of unemployment after the first dot-com bubble burst, I
met a woman who had been unemployed for two or three years, and she had COBOL
experience. We got jobs within about a month of each other (she recommended me
for a company that hired me, then I recommended her for a managerial opening
at the same place), at a Java shop. So at least one of the following must be
true:

* employers weren't all that desperate for COBOL programmers

* hiring managers in the COBOL world tended to be male chauvinist pigs

* this woman preferred unemployment to working in a COBOL shop

------
Tichy
Wow - at times I have pondered learning COBOL for fun, as I assumed it to be
an easy language. That code snippet killed that illusion good and proper.

If I was religious I would now pray that I will never, never, never ever have
to deal with COBOL, ever.

~~~
bitwize
Everybody goes through that. "COBOL? What's the big deal? I think I'll try
learning it some weekend."

Then they actually try learning it.

Then they are enlightened.

------
giardini
COBOL has fixed point maths built-in, ergo it's popularity in accounting and
business applications.

Most COBOL code is straightforward file "read-process-output". I could easily
see a system that _generated_ COBOL code to do assigned tasks: the generator
would maintain the database and a description of transformations. The
developer would work at that level and never look at COBOL code.

But someone's probably written such a system in COBOL!-)

------
brown9-2
A grand total of 61 questions have been tagged on StackOverflow with 'cobol':
<http://stackoverflow.com/questions/tagged/cobol>

For comparsion, the count for "C#" is over 30,000, ".net" is close to 20,000,
and "java" is about 17,000.

------
edw519
#5 Phillips Screwdrivers: Everywhere and Nowhere

Just because you take your car to Pep Boys, call the landlord when something
breaks, and use power tools in the garage doesn't mean that olders tools don't
serve their purpose.

COBOL is just another tool in the hacker's toolbox. It does a great job at
what it was meant to do (neatly laying out and processing business
transactions) and continues to do so.

I have worked on many COBOL systems and choose not to any more. Why? Just too
damn many lines of code to do the same thing as many other languages.

I wouldn't worry too much about the supply of programmers for aging COBOL
systems. Supply and demand will take care of that. Which would you rather do,
web work for $50K or COBOL maintenance for $100K? Many would choose the
latter.

