1. 16

  2. 20

    This joke seems appropriate.

    A Cobol programmer made so much money doing Y2K remediation that he was able to have himself cryogenically frozen when he died. One day in the future, he was unexpectedly resurrected.
    When he asked why he was unfrozen, he was told:
    “It’s the year 9999 - and you know Cobol”

    1. 17

      The most telling evidence of COBOL’s irrelevancy is that about 70% of universities said they don’t even include COBOL in their computer science curriculum anymore, according to a recent survey.

      30% of universities are teaching COBOL?

      1. 3

        “Micro Focus said that 73% of the universities polled don’t offer Cobol programming classes. Of the rest, 18% have Cobol as part of their core curriculum and 9% offer Cobol courses as electives.”


        Pretty surprising. Institutions change slowly I suppose.

      2. 7

        They’re just delaying the inevitable, COBOL only exists on some mainframes of banks and other companies, and with the language itself lacking publicly available specs and implementations, learning is only available to those who have bought old books or had special courses.

        This was OK in the 60/70s, where mainframes were the only viable option for enterprise and computers weren’t something people had at home and could mess with.. but we’re so much past that period now.

        I also suspect those companies will be managing their precious last COBOL programmer just like they did 30 years ago, and I don’t think an higher salary would ever be worth that.

        1. 3

          and with the language itself lacking publicly available specs and implementations

          Huh? It’ll cost you, but the latest ANSI standard can be purchased, and GNU Cobol, while not striving for full compliance, does pretty well according to their FAQ.

          I’m sure COBOL will go away, but I don’t think it’ll be as fast as people think.

          1. 4

            By “lacking public specs”, I was kinda referring more at the fact that COBOL has no real standard.. sure there is ANSI COBOL, but most COBOL deployments are on IBM/HP/etc mainframes with their own dialect and everything.

            Also 157$ is an incredibly expensive price, something I’d never spend when the market has opportunities for more supported languages.

            I tried GNU Cobol once, it’s a mess. It may be up to specs but since it’s not really a compiler (it “compiles” to C code) the errors messages I got were complete garbage and after hours of trying I couldn’t figure out why my basic programs wouldn’t compile. It’s not helpful as a learning tool and companies who use COBOL will probably use something else anyway.

            I haven’t tried Visual COBOL though, so maybe that might be a working solution for the non-enterprisey.

        2. 6

          Every time I read an article like this, I look for how the author is connected to MicroFocus.

          1. [Comment removed by author]

            1. 4

              but isn’t it more likely that, as business needs change, people will first write wrappers around the COBOL, then start to phase it out in favor of more modern languages?

              For the sake of both the people maintaining the code base & the business running on it I really really hope you are incorrect. Unfortunately I saw it happen at my previous job. Core banking system written in Oracle PL/SQL. There were a lot of attempts going mostly from upper management to move the code base to ‘something else’ or modernizing it by introducing OOP (which PL/SQL supports but it’s a hacky & under performing mess).

              I worked at that place for 7 years, the language was rarely the problem. There is a moment when you click after working with a code base for about 2-3 years - from that moment you generally even don’t think about the language but the business you are essentially encoding. People were accustomed to the language & the system. Brining a new person in had a cost of allowing a person to learn for 3 months, then working with guidance from someone else & being fully self sustaining after an year. You guessed it, the longest learning curve is the business & system design vs the language.

              By enforcing moves towards Java & OOP. Parts of the system are now in Java, parts are OOP. Performance degraded a lot and the whole thing is a lot harder to debug/diagnose. When I speak to my old co-workers after leaving, the technicalities of the language & design are now as big of a problem as initially the business issues were.

              The moral of the story is: Better the devil you know than the devil you don’t know

            2. 3

              I think that this is going to be a continual change that will hardly be noticed. In fact, continual change is probably already happening. Let me explain: I’d bet that at least half of these 55-year-old programmers picked COBOL up in the past 15 years. (A 55-year-old programmer, now, was my age during the early 90s. So it’s not like she wasn’t exposed to C and Java and Python and Lisp and Haskell.) It’s not like they’re some dying breed. People can, and of course do, change languages, and people who wouldn’t deign to work in “the enterprise” while young tend to change their opinions as they get older.

              One thing that happens with age is that people get more tolerant of boring jobs, not because they’re more mature, but because there’s a secret advantage to being the guy who works on the boring stuff (e.g. the database admin or the COBOL maintainer): your boss finds it boring, too, and leaves you alone. The amount of executive meddling you have to deal with if you work on “the fun stuff” is generally much higher, and that usually means that the politically powerful people take the meat and leave you with the grungy part of the project anyway. I’ve met plenty of very good 50+ year-old programmers who now work as DBAs at “boring” companies because they’re sick of having useless change shoved down their throats by 28-year-old VPs who don’t know what the fuck they are doing. So, I’d bet that most of those 55-year-old programmers picked up COBOL recently, and 20 years from now the 55-year-old programmers working on COBOL systems will people who have never used it as of this time, and everything will be just fine because, guess what, a large number of those 55-year-old programmers are really fucking good at their jobs.

              In terms of economic time bombs, I worry more about Java (21st-century COBOL) than about COBOL itself. I really don’t think that the 55-year-old COBOL programmer making $250,000 per year is overpaid at all. That’s less than I expect to be making at that age, if I stay in this game. On the other hand, we have a lot of ridiculously overpaid and mediocre Java programmers running around: I’m talking about people who pull down $500,000 and up and wouldn’t even be 25th percentile if they jumped into a real programming community like Haskell. They get to that level by consistently setting up bidding wars for themselves (and, I mean, good for them; perhaps I’m a bit envious). Haskell programmers don’t get to do that, because Haskell jobs are rare, and you can’t change jobs every 18 months and keep a coherent career. COBOL programmers probably don’t get to do that very often, because I’d imagine that COBOL jobs are rarer than Java jobs. But because there’s such a flood of interchangeable Java jobs, a Java engineer can set up a bidding war every 2 years and, after a few iterations of this, take the whole store. The worst bit of this isn’t that they make a lot of money (again, good for them) but that they parlay this into power; Hooli can’t justify $500,000 for a mediocre Java programmer unless it gives him a VP-level title, and suddenly a guy whose career choices show a mercenary angle and a lack of taste when it comes to programming tools is the ranking engineer.

              No, I’m not forecasting a “Java apocalypse”. There’s so much money in software that the ecosystem tolerates a great deal of pain and waste. However, when you have people getting paid huge amounts of money to write crappy line-of-business Java code, the incentive becomes protecting an income rather than career growth and mastery of the discipline. (I mean, who wouldn’t go to many lengths to protect a $500k income?) Then you have people developing systems with no intention of handing them off, instead trying to make themselves as irreplaceable as possible. Many legacy messes are unintentional (deadlines, technical debt) but when you overpay so massively for what is technically the wrong thing (VibratorVisitorFactory decline patterns, “Agile” and scrotum and loser stories) you create the intentional kind of legacy disaster. Those tend to be the hairiest of all because, while these people are mediocre programmers with a lack of taste, it would be a mistake to suppose that they’re not intelligent (they’re sharp as hell, or they wouldn’t have gotten those $400k-2M+ jobs at Bay Area megacorps; they just don’t value good code). They know how to protect an income. So don’t expect documentation.

              The worst legacy time bombs that exist right now aren’t in COBOL, because most of those systems are old and Just Work and won’t be replaced so long as that remains the case. (Seriously, why throw out working code just because you don’t like the language that it’s in?) Rather, they’re in Java and most have been written in the past 10 years. This isn’t going to grind society to a halt, though. It’s just going to be an annoying problem that cash-flush businesses throw huge amounts of money at. And maybe there will be demand for static analysis capability and all of us Haskell programmers will be in demand.

              1. 5

                Serious question: are there really any significant number of people pulling down $500K/year for coding aside from a tiny handful of very, very niche cases (say, a few HFT finance jobs or Bay Area startups paid mostly in stock that ends up paying off big at IPO)? I don’t think I’ve run into anybody making anything like that in my career… but, how would I know?

                1. 4

                  It’s obviously not the norm (i.e. you don’t get that kind of salary just by being a mediocre Java programmer) but it’s many more than “a tiny handful of very, very nice cases”. Google and Amazon and Uber aren’t startups and have plenty of people making that kind of money.

                  It requires playing the game, and you have to be not only mercenary with regard to companies (who isn’t, these days?) but also with regard to technologies, and dedicated to acquiring money and power at any cost. You can’t say, “I only want to do machine learning” or “I want to use Haskell” or “I prefer not to manage more than 5 people”. You have to optimize for job titles, status, and money at the cost of everything else.

                  Typically, this means that you end up doing a lot of Java. The good news for many such people is that, if you play the game well, you can get other people to do it for you. It does mean that you stop coding and become a non-tech, while continuing to market yourself as a “10x engineer”.

              2. 1

                Damn 220B lines.

                Well the best to go about avoiding cobol would be to use an intermediate virtual machine like jvm, porting modern languages to mainframes, putting the legacy code in a facade of Service Layer or FFI, migrating the data into a common store, source-source translation of COBOL …

                I find it disheartening when programmers think that a clean-room implementation is the only way to go. Heck I wouldn’t mind a COBOL gig if a line a code can actually help someone run their businesses safer, faster. Nerding out on languages is just horribly limiting.

                1. 1

                  Is the concern that programmers today don’t understand COBOL or that they don’t understand the business logic that these COBOL programs encode? My understanding of the COBOL gap problem isn’t so much that COBOL programmers are retiring without replacement COBOL programmers, but that these programmers are the only ones who understand the business logic in these programs and this knowledge isn’t being transferred to the younger generation.