Jonathan Blow has a point that we cannot assume things will keep getting better. Although he says that we cannot fix software because we have chronically not done it for decades, his thesis is that the solution is to make software simpler. The issue I have with making things simpler is that if we don’t know how to fix things because we haven’t done it for decades, how can we make things simpler, when we haven’t done THAT for decades either? His argument rejects human exceptionalism, while also relying on it for his solution.

My point is that this absolutely is a funding and priority issue. I work as a developer who maintains legacy FORTRAN code. It was written in an era where global variables and Go To statements were the norm. Everyone who wrote it is retired or dead. It’s a pain to work with and there are parts that I haven’t yet gathered the courage to go in and change. However, me and my team have made substantive changes to it that are robust, that we have rigorously tested. This is not impossible, but it’s also not cheap or fast. It took me a year to understand how this blob of code works.

My team is young, we’re in our 20s, with backgrounds in CS, mechanical engineering, and physics. Certainly all systems are different, but if we can understand old FORTRAN, similar people can understand old COBOL. If people made it, people can understand it. We also know how to fix many broken things and how to fix many bugs. Often were told by management “not right now” and “we don’t have funding for that.” It’s frustrating, but that’s how the world works. They at least have funding to pay us to do what we’re doing now.

The point is that you can fix legacy systems, you can hire new people to do it, but it is expensive and it takes time. The whole issue is not whether we can or can’t, we can. The issue is: who can pay for it and will they?

This is a very hard problem. Not a silver bullet but I’ve often found that metrics are the best way (again not guaranteed) to get the money (wo)men on board. If you can demonstrate concretely how the legacy code affects your operational readiness or agility, it might make it a better sell to invest in refactoring. However the lack of standard tools to do this is a problem.

The problem with code is that most non technical companies don’t have a clue how this thing works. They use analogies. And for most folks the analogy is that of a machine that once built never breaks down. If you can demonstrate viscerally how bad the system is, it can help get better support.

For all of these large, old organisations that still use COBOL, the risk isn’t that they run out of COBOL engineers to hire. COBOL is a very simple programming language, it was designed to be as simple as SQL. SQL was designed to be so easy that non-programmer business analysts could use it, COBOL was designed to be the same thing, but for non-DB business logic. Though you could debate how successful either of them were.

The risk these organisations face is finding people capable of maintaining their particular decades old COBOL spaghetti. Which is really just an ordinary key person risk.

The irony for me is that SQL is the language that stood up the test of time the most. All other are/were gamble.

Obviously it's not fit for all domains, since it's a DSL for data management, but I'm often tempted to push as much business logic into the DB with PL as I'm allowed to instead of having to do things in the application code itself, and it paid off many times, as I have rarely seen a project moving from a database to another, while application code is often rewritten in many different languages for no other reason than management's whims. I probably saved some businesses millions of dollars in code porting/rewriting/migration.

> The risk these organisations face is finding people capable of maintaining their particular decades old COBOL spaghetti. Which is really just an ordinary key person risk.

In my experience, the biggest issue is the complete lack of code documentation, as organisations relies on a handful of developers to maintain their codebases and when these developers retire, suddenly, nobody can understand an architecture.

I actively avoid companies that put all of their logic in the DB. It’s harder to version control, harder to unit test, much more work to rollback. You can’t keep it in sync with the source code etc.

I can’t just switch branches and know the state of the system at the time the branch was created.

You're making good points.

First, I'm talking about a PL "middleware" layer than does not necessarily involves restructuring the data itself (basically, instead of querying tables or views, you query stored procedures or functions).

When it comes to version control, wouldn't a migration system suffice to assess the state of that layer?

As for unit testing, I kind of agree, it's possible though, like any other programming language.

That doesn’t help. You can’t imagine the times I see

  Get_Customer_1
  Get_Customer_2
  Get_Customer_3

As far as version control, if someone does make a change to the unversioned “Get_Customer” and I want to switch branches. How do I make sure all of the stored procedures are in sync?

This is pretty much my experience with stored proc codebases too. I do consider SQL to be a very simple language, but store proc codebases tend to become incredibly complex. Finding an engineer that can maintain SQL code is very easy. Finding one that can maintain a particular maze of 1000+ stored procedures, views, functions, table triggers... is a completely different question.

Many generational skills die out. Your grandparents would make their own butter, bread, many things today that are not so common. Then more, many skills lost over time and fact we are still working out some historical things got created, you can imagine rosetta code sites being a good thing to keep alive for the future. http://rosettacode.org/wiki/Rosetta_Code

The difference you're missing is we're still relying on COBOL, but we aren't relying on grandparents to make the butter and bread we eat lest we starve.

Not ideal, but it's not like it couldn't be migrated to another language and COBOL docs are readily available to at least understand the language. We would find a way.

I've worked for a software migration company and for some languages and the bulk of code you can automate the migration. However you also need to migrate the data and then anything that touches that data, so whilst you may want to migrate one program, that program will be a suit of programs and systems making it a more complicated task than it appears on the surface.

If you can data warehouse aspects off, that's great and can slowly bite away, migrate chunks bit by bit. Though one of the last will often be the database itself. Report generation is often an area that will hit resources hard and can also be easiest to migrate away towards something better using a system that periodically syncs the database onto another platform with all the latest do it yourself easy accessible tools. That allows those wanting the reports to be able to make and change that themselves removing a lot of code development and main system overhead.

With that, knowing the language is not even half the battle, the business knowledge would be the lion's share and to integrate the two skills effectively, that's where the money is.

You could have a payroll system, migrate line by line, logic by logic from COBOL to C. Yet the way the data is handled, the nuances of the way the languages round numbers, store data, formats, handle exceptions or early termination. It's not just a case of setting the right flags in the compiler and job done.

But yes, there is always a way. As always, the devil is in the detail.

One solution I saw somewhere here on HN the last time it came up was to carefully virtualize the existing systems so they have snapshots to restore from when things go wrong. That opens the possibility of moving the data to more modern systems with a translation layer between the 40 year old systems and the new systems that slowly replace them.

If you think of the butter as software running upon a compter and the process of manufacture the programming language, then you start to see it differently.

Though my main point I was making is that skills get lost over time for various reasons and how later you try to rediscover those skills for various reasons. I dare say that being able to make butter would be handy in some situations, imagine being isolated and access to a cow milk easily and your local shop not having any butter in stock for a while.

> Your grandparents would make their own butter, bread, many things today that are not so common.

I've never made butter, but I have used raw milk. And I've failed at whipping cream, by overdoing it. So from what I've seen, "making butter" is basically just agitating cream until the fat clumps, and then pressing out the whey.

Making bread, I admit, takes more skill.

My mother knew how to make blood pudding. But that's not something I miss very much.

Given enough time I'm sure we can figure it out. The problem is that they're not looking for archaeologists, they're looking for people who lived among the dinosaurs.

Like Gibson's remark about the future already being here but not evenly distributed, the collapse is already happening but unevenly distributed.

Puerto Rico was without electricity for months. Some parts of the West will recover from the economic effect of the pandemic quickly. Others won't, without help from the center.

How is that different from say 1918? Centralization?

> then civilization as we know it becomes one more step closer towards total irrecoverable collapse.

I love how pop culture always portrays the collapse as coming from our inability to maintain or repair some mythical machine or technology. Never once did I imagine that it was the state welfare software.