One of the real gotchas in old systems is the data limits. So systems working fine, all working with say a name field that's locked in at 40 characters as that when original designed was enough and storage wasn't cheap then. Or a comments field, 250 characters felt generous back then, today - that's the first sentence just about.
So you get old fine working do the job systems, then you get what I call bolt-ons to those systems, web front-end and the like that all distill the input into a format the old working system can take in. Which is fine, but the data limits of the back-end really do start to stand out more and more then and seen many a case of a front-end allowing more input only for it to get blindly truncated before it is fed into the backend. Things like that can and do create interesting issues. Though as true today as it was back when COBOL was born - garbage in garbage out.
Isn't that a matter of abstraction? We have to consider the old backend a type of "virtual machine" with a domain-specific instruction set. Of course, this is a rather funny virtual machine with some odd technical limitations, but it's not infeasible to consider writing a new back-end (middle end? middle...ware?) that targets the old funny backend but abstracts over its limitations e.g. by using two records to get additional name storage.
Depending on how complicated the business logic rules encoded in the old backend are, could this be more efficient than modifying the old backend?
Generally and for many things, augmenting the existing backend is the best way over a rewrite which would take more than 5 years for many systems and with that, get shot down by accountants and management bureaucracy. As for the VM analogy, hmmmm from a data perspective, maybe.
But it all boils down to how the old system stores data, and some will enable you to hold multiple records and for example a comments field. May have the last character closed of from input as it is a continuation marker that means there is another record and they are joined, as you say two records. Changes like that will entail changes to the backend, though the impact can be more manageable than alternatives.
Then you can use replication or data warehousing and from that, lots of reports and other aspects that would hammer the backend become much more pleasant.
Crux is the limitations, things like names, so entwined into a system that it does not lend itself to the two records solution. So you use another solution.
You mention business rules and that is very much key and having somebody who knows the business logic is way more valuable to understanding the a system than knowing the language it is written in. So as an aside, if I had to employ somebody to work on an old legacy system, I'd take the person who knew or showed a grasp of the business logic and how that works over somebody who knew COBOL. As it is easier to teach COBOL than an entire business. COBOL has many books and resources, a business tends not to have such clear cut documentation.
> News flash: the C programming language is the most popular language in the world and it’s nearly as old as COBOL. SQL is the backbone of database programming, and it was invented in the 1970s. The age of a technology is no indicator of its viability or appropriateness for solving mission-critical problems.
The big issue with COBOL is developer availability. I can easily find a lot of C programmers to fix and extend my complicated C code base. I can easily find a lot of programmers familiar with SQL to help me fix and improve or change my queries. Finding COBOL programmers is a much harder task and C and SQL programmers.
And it is not about the age of the programming language. My guess is that it would be harder finding PL/1 or Algol 60 programmers even though both of those languages are newer than COBOL.
I think Cobol programmers get $60k in Austin, which is about $20k a year less than the lowest paid Java developer gets in the area, so I would guess that the shortage is a result of low pay. Also, Cobol depends on a lot of institutional knowledge since they are not likely to be building greenfield systems. This would make it hard for someone who knew the Cobol language to really know what the system they are programming on does and get started extending its usage. And it seems like the less a programmer is paid, the less patience management has with them.
MARK IV is the oldest language in use that I know of that I have personally had contact with, and I've had contact with it recently. I would say that the issue isn't just finding Cobol programmers, but a mix of mainframe specific languages and technologies no longer in wide use outside of mainframes' data warehouse solutions, such as DB2 and VSAM.
The main problem with Cobol, REXX, JCL and MARK IV is that the solutions/problems encountered cannot just be google'd through stackoverflow or some online forum. Institutional knowledge from 30 year experienced self-starters or solution specific candidates with 30 years of experience in a piece of the project needing assistance who is willing to be a self-starter for gaining experience enough in the other technologies the mainframe uses.
> I think Cobol programmers get $60k in Austin, which is about $20k a year less than the lowest paid Java developer gets in the area
On top of that they tend to be stodgy old corporate companies that developers hate, where you have to wear a suit to work and being seated by 9AM is more important than doing your job well. Then there's the fact that it could be career suicide to spend so long on tech that fewer and fewer companies are using. And you'll need an exit plan because it's used at become companies that do regular mass layoffs, they've probably fired more cobol programmers than they'll ever need. They should be paying a hefty premium to get people.
The language itself and surrounding systems can't be any worse than the standard enterprise XML DSL rubbish can it?
>On top of that they tend to be stodgy old corporate companies that developers hate, where you have to wear a suit to work and being seated by 9AM is more important than doing your job well.
That I can attest happens, less so today but then such places lost most of their talent as those that could and able to move on did and those that didn't, well they would of been close to retiring and with that. Hence technical debt increases. But it's not just knowing the COBOL, it's not just knowing that business logic, but how the two go together - THAT level of knowledge was always undervalued in many institutions alas.
The language itself and some of the tooling might be quaint, but I feel that sometimes it's also much simpler than the replacements from turn of the century. Not all corps are stodgy ones, but that's usually contractors that have few COBOL experts, sometimes just to check over work of other contractors. Some vendors are worse than others, some better.
Train them. We do it all the time with new hires or old pals for any mainstream or not language. I saw teams do marvels in a quarter in completely new languages, no matter how far the paradigm. Not claiming COBOL is easy (no idea) but can't be an impossible task. Is probably harder to keep people engaged
From what I understand talking to someone who gets paid enormous amounts of money to occasionally update COBOL systems in heavy industry, working on COBOL is drudgery.
It might be difficult to find a substantial number of people who actually want to be trained in COBOL.
There are a lot of developers who would like to be paid enormous amounts of money. I wonder if the public sector pays well enough to generate the desire to learn, though.
I myself can handle a lot of drudgery for $350k a year.
So is Java, and my last stint with Python definitely feels drudge-like too. Offer enough real money and appropriately structured career path (especially one that doesn't lead someone down path of "one language programmer") and you might find a team fast.
COBOL is really, really bad from the point of view of a developer. It's frustrating, verbose, and tends to produce huge spaghetti code.
Good developers - those who like what they do - won't touch it with a stick. People do OCaml, Haskell, Clojure in their spare time and C# and Java at work - but nobody codes COBOL in their spare time. People code in Assembly, sometimes in hand-assembled hexadecimal format, but not COBOL.
I think good developers don't really care so much about which language they work with, but rather care about solving interesting problems.
The language is just at tool; being fixated on OCaml or Haskell or whatnot seems like mistaking a tool for a goal.
I'd love the opportunity to work one of these applications. It's different from anything I've done before and all other things being equal is certainly seems more interesting than working on the 6162th ride hailing app or some ad-tech meaningless nonsense.
> COBOL is really, really bad from the point of view of a developer. It's frustrating, verbose, and tends to produce huge spaghetti code.
THAT is true of any language, the fact that COBOL has divisions does make it a bit easier. But you can also do very structored code in COBOL and code without using the GOTO verb. However many systems and code born the scars of the time. Fast code really did make a difference and was measurable in cost a lot more upon an expensive mainframe and when your processing near on a million records, very noticable in costs. So GOTO got used a lot, as coding for exception handling using structured programming like JSP (Jackson Structured Programming - the thing in the COBOL days) whilst doable, wasn't the fastest code and equally, not that readable if you didn't know the methodology behind JSP.
But over time you don't see the language, you see it from a data perspective and with that, code however laid out becomes easier to manage and by that, anybody else's code will look a bit yuk to you. Indeed it is rare to work on somebody else's code and come away with a warm fuzzy glow.
I don't think this article is fair. It is certainly the case that badmouthing COBOL for its age would be irrational, but I don't think that's what anyone is actually saying. People wouldn't react the same way in the system were written in C or LISP. COBOL has a reputation for being clunky and inexpressive and primitive for reasons other than its age.
Perhaps some popular articles dismissed COBOL for its age. No programmer worth their salt would do so.
(I can't say whether or not COBOL deserves its reputation, and given how many reliable systems are written in COBOL I doubt it is fair to blame it for the failures of this website.)
100% agree. The problems with these systems are usually the crap built around them. The IBM, Univac, Grumman, etc or state people who built this stuff 40 years ago knew their stuff. The operational processes are mature and don’t break.
Usually in a government agency is a layer of VB, J2EE from circa 2003, powerbuilder or some other array of old junk that is responsible for some business processes and is a make work program for hundreds of developers. That is the problem.
Whatever CIO is whining to the governor about COBOL need to be gone, now, and New Jersey needs to find somebody who can get the stuff around the COBOL reengineered and implemented quickly. Then start hacking the COBOL bits apart.
I don’t really understand this article. When the New Jersey government came out asking for Cobol programmers, all I remember was them talking about the strain on their system due to a demand spike. But this article spends its whole time talking about the UI? Unless I’m missing some context, this reads more like an ad.
It absolutely reads like an ad and an a pedantic ad to boot.
The system wasn't built to handle modern workloads, that might be part of why people decry it being ancient.
Despite starting out talking about architecture, which would be a difficult problem to tackle when having to interface with systems built around abstractions and conventions of a couple different eras back, more than half the article veers into the relatively easier task of user-centric UI design that his company can bill for.
I mean, that'd be great too, but the article is bait and switch.
Unemployment enrollment is a list of 30-130 questions + documentation, varying by state.
If you worked the same job for 5 years and got laid off, it’s closer to 30 questions. If you were laid off from a job after three months, worked at the post office in the last 3 years, got discharged from the national Guard with a service disability, it’s closer to 130 questions.
UI/UX is important because the business rules get complex and you can’t throw a random call center person at it — they need to know wtf they are talking about. You never have enough of those people. Making it a fully online transaction means someone needs to fully understand the business rules — which is harder than it sounds because new things get added often, and the old mainframes generally don’t get reengineered.
Also, when you say demand spike, in 2020, that means when all is said and done more UI applications than have been seen in the last 10 years, in a 60 day period.
This is the same info as I was aware of. The problem was crashing servers. But my complaint is that this article instead spends a lot of time complaining about the input forms
The problem might not be bad web form UX either. The general problem is one of a new code change requirement in a legacy system. Perhaps we should think about creating an On-Boarding document for new developers before dismantling the original development team, ready to bootstrap a new development team. It could be part of the regular business continuity plans that many companies actively maintain.
This has the feel of a corollary to Fred Brook’s The Mythical Man-Month; The Mythical Effective New Man After Many Inactive Months.
Interviewed at adHoc and while it's good they are fighting for pay parity and equality ... it was a turn off that not any one person could not negotiate their own worth.
Negotiation your salary I guess is something learned and those who work at this company are fairly new in their careers(i think). Personally, I am not, so and again I applaud this company's mission of equality and pay parity. Yet for someone seasoned it led to find other places to work.. places where negotiating ones worth is allowed.
There's something fascinating about a politician calling a bunch of people stupid for no reason. Like, he admits he's not good at coding, it's not like I'd take his word on tech decisions. This whole thing is so weird. You'd imagine he'd either have good taste, or try and pander to the most people. He's taken a third path, which I can't really place.
I think Lisp simply battles intuition for some people in a way that makes them upset until it becomes familiar. I also think Ted Lieu would have experienced this with COBOL
None of this really seems to be just COBOL's fault.
COBOL is a compiled language, so once compiled into machine language it doesn't matter as long as it runs.
I would be looking more at what hardware its on which is probably some Big Iron running system/360 that has a 2 week turnaround to add some extra memory. The code probably runs just fine, it's the hardware support cost and turnaround time that will be the constraint.
So, COBOL is lindy. Not because it's more efficient but because a complete rewrite is still more expensive and risky. Though I hear now and then that parts of those systems are being rewritten gradually (usually in C# as COBOL runs on the .NET framework). It's just a matter of time.
So you get old fine working do the job systems, then you get what I call bolt-ons to those systems, web front-end and the like that all distill the input into a format the old working system can take in. Which is fine, but the data limits of the back-end really do start to stand out more and more then and seen many a case of a front-end allowing more input only for it to get blindly truncated before it is fed into the backend. Things like that can and do create interesting issues. Though as true today as it was back when COBOL was born - garbage in garbage out.