I heard this number and a quick google search reveals a whole lot of touting this number and absolutely zero data (honestly most articles promoting COBOL read like 95% propoganda). Perhaps it's true in an extremely limited context of banking software or something, but with millions of applications coded in dozens of languages and near-zero new COBOL projects I don't see how this is possible.

Is this a myth from the 70s (when it would have seemed entirely plausible) or is there some limited definition where this is actually true? I know there is a great deal still being maintained and I'm sure a large % of businesses have at least one COBOL program around, but this invisible 70% seems absurd.

  • 2
    I think it is very heavily dependent on the industry and relative age of the IT infrastructure at the company. My internship was at a fortune 500 company that had heavy cobol usage and their main infrastructure was mainframe i-series and Cobol with db2. I now work at another fortune 500 that has to interface with an i-series back office system, but all of our applications are asp.net based and we use a replication package to get the data into sql server. Commented Oct 18, 2011 at 3:22
  • 3
    – vartec
    Commented Oct 18, 2011 at 11:27
  • @MattPhillips that seems possible, I know John Deere has virtual punch card machines to interface with what must be an ancient system, but with the massive amount of new programs being written and able to be written by nearly anyone I find it impossible to believe the 70% figure in any scope broader than a handful of very "legacy" (though potentially very important) companies.
    – Ben Brocka
    Commented Oct 18, 2011 at 13:11
  • @vartec That question's based on some similar numbers to what I've seen, but the lines of code statement seems irrelevant (and immeasurable, even compared to % of programs). That post further elaborates that the 70-80% figure appears to be based on the billions of lines of code figure though...meaning it's a meaningless vague metric based on another meaningless vague unsourced metric...which sounds more in line with reality.
    – Ben Brocka
    Commented Oct 18, 2011 at 13:17
  • 2
    Maybe in Lines of Code...probably not in sheer volume of programs.
    – CaffGeek
    Commented Oct 18, 2011 at 13:26

6 Answers 6


The COBOL wiki page cites the Gartner quote, but there isn't a source from Gartner provided. It is all over the Net. 80% of businesses, 200 billion lines of code, 5 billion new lines of code each year. Some places, the numbers vary a bit. However, one number is almost always missing from that Gartner quote on the COBOL wiki page, and missing number is the year. 1997. Let's assume the quote was true, in 1997.

I have worked in COBOL for 20 years, and for the last 13 years I have witnessed COBOL development disappear.

ERP solutions? The last one I know of that had at least some COBOL in the product was PeopleSoft, when I talked to PeopleSoft reps at an IT conference in 2004. I was working for the UW at that time, and I talked to literally dozens of people, maybe upwards of 100, from universities all over the country. A very common story was repeated. "We replaced our homegrown ERP solution, written in COBOL, with " PeopleSoft, Oracle, SAP, SunGard. Delve into the careers links of those companies, and look at IT positions. See if there is any mention of COBOL, DB2, CICS, etc.

Healthcare? Well, I worked for GE Healthcare for 3 years, and they were among the last hospital clinical software vendors writing in COBOL. 3 big layoffs in 3+ years, an office that dwindled from 600 employees to under 300 employees, clients converting to Epic or Cerner. Not a very bright future for COBOL there. Neither Epic nor Cerner writes in COBOL. Check out their career pages. McKesson appears to still be written in COBOL, but I see a number of hospitals converting away from them as well.

State and federal government might end up the last bastion of COBOL, but some of those projects have gone away. Completely replaced with .NET or Java.

At 44, I'm one of the youngest COBOLers I know. Oh, there are 5 or 6 I know who are younger than me, but the 100 or more others I know are probably on average 10-15 years my senior.

IBM 390 and zSeries, HP NonStop, Unisys 2200, and Unisys MCP are the big iron boxes out there running COBOL. Every one of them supports Java development. From what I have read and know Java on big iron, which is mostly limited to the HP NonStop, if it is done right then Java can replace COBOL over time.

There have been efforts, that I know of or worked on, since 1994 to replace clunky mainframe green screens with GUI front ends written in VB, .NET or Java.

A lot of COBOLers I talk to who are certain of COBOL's future are out of work, like me, and aren't finding work. Best shot I have is a state gig where there are likely more than a couple of people within a few years of retirement. Assuming I get in, I expect over the next couple of years my role will evolve into how to clean, efficiently, and without interrupting the business administer a lethal injection, figuratively speaking, to COBOL through step by step replacement.

Finally, back to Gartner. They charge for everything they publish, and it ain't cheap. But venture over to Gartner.com, set up a free account, go to the Research tab, and search on the keyword COBOL. You won't get the whole article, but you will get a summary and a snippet. Reading and analyzing Gartner's work, I think it's very clear they are signalling the death of COBOL.

  • Great expansive answer! Considering how terrible ERP solutions I've used it wouldn't surprise me if ours was still written in COBOL...
    – Ben Brocka
    Commented Oct 20, 2011 at 15:11

Depending on how you define the 100%, that number might be correct. For example, it might very well be that 70% of the programs written for banks and financial institutions until 2010 is based in COBOL. Wouldn't be surprised.

But I don't think that it is a fair statement to say that out of all the software in the world, 70% would be written in COBOL. Frankly, I don't know if you can even measure it.


the Gartner Group reported that 80% of the world's business ran on COBOL with over 200 billion lines of code in existence and with an estimated 5 billion lines of new code annually. Source is: COBOL-1.

I have no idea how do they count these numbers. I worked in several companies where no one actually tried to count all lines of code in one shop accurately, even when it was used as a measure of complexity. So how did they come up with these numbers?

COBOL is alive and well. It is not true to say that there are zero projects starting using COBOL. Remember that lots of the enterprise projects are interdependent. Unless there is a reason to extend a project in a different language you use the original architecture and software. Remember that most of such systems are large and re-writing them in a different language is risky, expensive and usually adds little or no value to the business.

There are many resources on the net that tells us that COBOL is alive and well.

  • I have no doubt that it's unfortunately alive and well, but the claims I've seen seem patently absurd unless they're talking about a very narrow scope. For instance it would seem like about 1% of new programming jobs are specifically for COBOL, yet 70% of infrastructure is COBOL? Unless all of this COBOL is beyond transparent I just don't see it.
    – Ben Brocka
    Commented Oct 18, 2011 at 13:13
  • I personally don't think that the demand for COBOL is as strong as the demand for JAVA or .NET skills. Lines of code is a very bad measure because it hides a lot of detail. One line of code may be translated to 10s of lines of code by COBOL CICS pre-Compiler for example. I am not sure where you got your figure 1%, but in my opinion this is too low. The low number of new programmers getting into COBOL may be attributed on lack of interest of new programmers to learn COBOL and to the fact that most COBOL programmers don't switch jobs often. But this does not justify the 1% still!
    – NoChance
    Commented Oct 18, 2011 at 13:33
  • In addition to the above, outsourcing effect is huge. It is possible that since many of the system functions are outsourced to other countries, the local demand (in USA, for example) has fallen but the external demand has risen. In some countries it is enough to just get a job. Some people are not picky.
    – NoChance
    Commented Oct 18, 2011 at 13:46
  • Anecdotal evidence on SO (246 questions about COBOL) is that it is in decline (or the existing COBOL programers don't use the web or stack overflow or already know everything and don't need to ask questions). Commented Oct 19, 2011 at 8:28
  • @LokiAstari, good catch!
    – NoChance
    Commented Oct 19, 2011 at 9:41

I think these figures date to about around 1997 when the Y2K "problem" was the hot topic in IT (especially sales people out to make a quick buck!). At the time there were some serious attempts to find out how much COBOL/C/C++/Java/VB etc. code was actually running to get a grip on how much work was required. It came as a shock to people how much of the worlds code base was COBOL.

I would expect this figure to be a lot less now, partly because of the long slow decline of the COBOL but mostly because there is a lot of code been written in other languages since then. Just think, php, barely existed in 1997.

  • Until about 10 years ago it was hard to get a compiler/interpreter for your computer. Thus very few people could code. With the explosion of the web and web based languages (and slightly more because compilers are now much more common and free (gcc pre 3.0 was nearly unusable (and required a lot of work, Java came of age at about the same time)) now anybody and his brother can write bad code without any real training. Commented Oct 19, 2011 at 16:23

First of all, these estimates are dubious. Secondly even if you'd assume that the numbers are correct, the estimates are based on lines of code (LoC) metric. COBOL is extremely verbose, so you need an order of magnitude more code to achieve same thing. Consider "hello world" in 3 programming languages:


print "Hello world!"


#include <stdio.h>

int main() {
    printf("Hello world!\n");


100300 BEGIN.
100500     DISPLAY "Hello world!" LINE 15 POSITION 10.
100600     STOP RUN.
100800     EXIT.
  • I've heard the verbosity claim isn't as true as it appears, but at the same time I've heard COBOL has no libraries, so I imagine there's a few billion redundant lines of code for every one billion lines of original code to say the least...
    – Ben Brocka
    Commented Oct 18, 2011 at 13:14
  • 3
    This is a really poor example because Hello World is a pathological case. The implementation is so short that the fixed overhead for both COBOL and C dwarf it, especially if you expand the #include to the contents of stdio.h. For meatier tasks like reading, dissecting and processing records, which is what COBOL was bred to do, a program in standard COBOL will be a lot shorter than the equivalent standard C program. Bottom line: pick the right tool for the job.
    – Blrfl
    Commented Oct 18, 2011 at 13:17
  • This compares really well with J2EEs (Websphere v4.0) 3000+ line Hello world example. Also the actual Code golf for a COBOL "Hello World" is 6 lines. Commented Oct 19, 2011 at 1:26

I have previously worked at a (largish) bank, and there COBOL was used for all core banking logic, with anything outside of that being done in either Java or C#. Although it's impossible for me to be sure about exact lines of code, I believe the 70% claim to be extremely dubious, in my experience. It is possible COBOL is more verbose as vartec points out above, but in terms of functionality implemented, the Java and C# "auxiliary" software was handling far more.

As a a typical example, the COBOL code was in charge of actually creating accounts, calculating interest, generating basic statements, as well as business rules around managing of the state of an account (access / valid actions). To be fair, that's not an insignificant amount of code - but compared to this, the "auxiliary" software was in charge of everything from receiving faxes, document splitting indexing, document storage / management, routing work to individuals, several thousand (sadly, yes) screens for data capture and managing the lengthy lifecycle of various processes that end in account creation, electronic interfaces to other companies and legal services, integration with the telephony platform, and many, many more functions.

Looking at it from this angle, I am fairly sure that the number would have been in favour of the Java / C# code, but again, I don't have any hard numbers to back up this claim.

  • You have obviously never looked too deeply into the interest calculations used in banking. The rules for a single interest payment calculation can go to about thirty pages, and, there are different rules for every product/account type. Compared with this receiving a FAX, or archiving a document is trivial. Commented Oct 19, 2011 at 1:31
  • @JamesAnderson - "compared with this... is trivial" - no, not really; just as with the interest calculations, there are complexities at every level regarding product / account types, so I am not really sure what you are trying to say.
    – Daniel B
    Commented Oct 19, 2011 at 6:08
  • I blame those program primer books that illustrate a debit credit transaction with five lines of Java. Core banking is an incredibly complex subject and the accuracy/reliability requirements are exceptionally high. I have seen dozens of projects to replace "the old COBOL" system which either failed completely, or, succeed by replacing it with another COBOL based system (mostly a package but in a couple of cases a complete in-house re-write). I have never seen one of these "old" systems replaced by anything else. Commented Oct 19, 2011 at 6:24

Not the answer you're looking for? Browse other questions tagged or ask your own question.