With old systems the catches always seem to be knowing the deep hidden why's to the encoded business rules and all the bugs, not just the high level goals and basic code.
Older systems have tons and tons of business logic encoded in them to handle edge cases and those functions will be in odd places, and then downstream systems have tons of logic in them to handle (and expect) bugs that your original system has.
Saying "let's rewrite a System that does X" is fine, but you also need to know all the arcane business rules and weird bugs in the system that aren't nicely spelled out in docs, or requirements, or some config file, but are nested deep deep inside in the app, hidden in unexpected places. The complex interactions of these functions generates the complexity, not just "Cobol". 50 years of rushed additions of weird rules to handle years past incidents or business logic changes.
Especially with old finance, insurance, and other systems that have this sort of longevity the original people who knew the why's have long since left. Any attempts to optimize, fix rules, fix bugs etc will produce a beautiful new clean system that's performant and simple and doesn't work at all.
A good re-engineering of any legacy system starts with logging. Reading code is simple, just use your eyes. But understanding what the code actually does requires knowledge of not just code but also data. The data that actually flows through the system on a regular basis and how it gets transformed from one function call to the next.
The next necessary step is piecemeal migration. You're not going to be able to process all request types from the get go. Start with building a new system that handles form A and leave forms B through Z to the existing system. The next project will be to tackle form B, and so on.
If either of these steps isn't possible (due to dysfunctional management, usually) then the project is doomed to fail.
The problem like assembler or god forbid vacuum tube based old system is those edge cases … hard to log them or eyeball them. Then once a year or certain event, the logic happened. Old system worked. Yours don’t. … sigh
The problem is that the business processes (A) are not understood, (B) are not deterministic, (C) are too complicated to implement in maintainable code (in any language). Everything flows from the effort to conceal these facts. That is the reason for the market dominance of IBM, and Oracle, and Microsoft: they are effective as partners in concealment.
The post misses the advantages of other languages, specifically to make this easier:
> Once you know how to program, learning programming languages is easy. Understanding existing programs is hard. Maintaining existing programs (in the form of what we call refactoring) is the most difficult part, by far.
Static typing, with generics etc means that you can use more proven libraries that are well-understood and not custom/special in each instance.
Immutable data-structures means you can reason about the function being applied without hidden side-effects, accelerating understanding of a new system and limiting unintended consequences, etc.
I worked about a decade in the 90's at a company providing code generation and source analysis tools to (banking, insurance, telco, etc) companies that used Cobol. The language can do everything (I've made Windows and OS/2 GUI programs with it), as can any Turing complete language, but it's not the best. The most I could say about it is that it's like Golang, where you're sort of steered away from over-complicating a program, but with Cobol you still don't have the tools to really simplify it either.
People who don't choose and use better tools are not part of the solution.
When I worked at the company (now defunct), I had a several product suites to recommend, mostly based on metaprogramming and reuse of source components. Now I don't have any skin in the game, and leave it to those 'in the thick of it' to decide.
The specific problem with COBOL is that COBOL is both a language that was badly designed on the day it was created and that there is a stigma against programmers who have worked with it. This stigma is also a problem for other languages such as Visual Basic and PHP and it can make it harder to find programmers willing to work in those languages. Nobody wants to be "unemployable" because they worked in a stigmatized programming language even though the idea of stigmatizing programming languages is objectively idiotic.
This wouldn't be a problem if organizations that are still using COBOL code would pay high salaries for COBOL programmers because there are people who are only writing code for the money who'd be happy to work with a terrible programming language if it makes them money. But they generally also want to pay antiquated salaries from decades ago for COBOL jobs if they even offer a salary at all. Because they would have migrated their system off of COBOL decades ago if they actually cared about properly maintaining it!
Not sure if COBOL is actually 'stigmatized', but it definitely doesn't match the experience requirements in the job postings for most places where young programmers want to end up.
It might well make a "second half of a career" job for not-quite-so-young programmers looking for an alternative to the tech-stack-of-the-month carousel. But the jobs tend to be with big old orgs (so, start with banks and government), which might not seem so attractive.
I think `COBOL` is (nowadays) a catch-all term for `COBOL` &/ `IBM assembler` &/ `IMS/hierarchical databases` and/or batch jobs. I can't fault a journalist for referring to all of that inexactly by `COBOL`.
Second, maintainability is absolutely not given freely. A gov't merely "purchasing software" does not necessarily get them the source code, let alone proper documentation. Seriously. Contractors have no incentive to make things easy for you, and all the incentive to make it hard. The tail often wags the dog.
"The powerpoint slides didn't say anything about lock-in" &c &c &c
I remember seeing articles that showed this specific issue was not COBOL itself, but the WEB front end(s) to that system. Seems they blamed COBOL for clicks.
> The real problem is, and always has been, the fact that the failed systems hadn't been maintained properly.
This is like Cyber Security on modern systems, cheap is always the way to go. Two different problems, same root cause. Management will always do it on the cheap.
Bloomber's Odd Losts podcast had two episodes on the general topic (Jan 2023), "Why Corporate America Still Runs on Ancient Software That Breaks":
> Southwest Airlines had a disastrous holiday season, thanks in part to a software bug that left crews out of place and grounded thousands of flights. But Southwest isn't alone in having software in the headlines lately. The New York Stock Exchange recently had a software error that caused weird pricing on stocks and the FAA had its own computer issue that grounded planes earlier this month. So what's the deal with corporate software? Why do these crashes happen? And why does the user experience typically leave something to be desired? On this episode of the podcast we speak with Patrick McKenzie, an expert on engineering and infrastructure, who writes the Bits About Money newsletter and recently left payments company Stripe after six years. We talked about the challenges of keeping any software system alive after years of upgrades and updates, the distribution of tech talent across industries, and whether non-tech companies can close the gap with Silicon Valley.
"This Is What Happens When Governments Build Software" (Jun 2023):
> There's a lot of frustration about the government's ability to build things in the US. Subways. Bridges. High-speed rail. Electricity transmission. But there's another crucial area where the public sector often struggles, and that is software. We saw it with the infamous rollout of Obamacare. We see it in the UX of the Treasury Direct website. And we saw it in the way state unemployment insurance systems broke during the pandemic. So why is it so hard for the public sector to build and maintain software? On this episode we speak with Jennifer Pahlka, the founder and former executive director of Code for America and author of the new book Recoding America: Why Government Is Failing in the Digital Age and How We Can Do Better, as well as Dave Guarino, who recently left the Department of Labor after working on upgrading the unemployment insurance system. Both have a long history of working on public sector software systems and they explain why the problem is so tricky.
One large component is that a lot of business rules and policies have been encoded into the software logic, and (re-)translating that into code in a new(er) language is part of the challenge.
> One large component is that a lot of business rules and policies have been encoded into the software logic, and (re-)translating that into code in a new(er) language is part of the challenge.
It's a massive challenge.
It's like a little city that has been growing for 5 decades with a new lot of houses here, a new road there, utilities routed over there, etc. Then someone saying "let's re-do this city about 10 miles that way".
With a city it's easy to see the magnitude of the problem. With large software systems it's not.
Older systems have tons and tons of business logic encoded in them to handle edge cases and those functions will be in odd places, and then downstream systems have tons of logic in them to handle (and expect) bugs that your original system has.
Saying "let's rewrite a System that does X" is fine, but you also need to know all the arcane business rules and weird bugs in the system that aren't nicely spelled out in docs, or requirements, or some config file, but are nested deep deep inside in the app, hidden in unexpected places. The complex interactions of these functions generates the complexity, not just "Cobol". 50 years of rushed additions of weird rules to handle years past incidents or business logic changes.
Especially with old finance, insurance, and other systems that have this sort of longevity the original people who knew the why's have long since left. Any attempts to optimize, fix rules, fix bugs etc will produce a beautiful new clean system that's performant and simple and doesn't work at all.