Is this a question the industry actually cares about? If anything, I'd say it got much worse at creating long-living software. It sucks to run a mainframe-based system from 50 years ago, but running a 10-year-old Web Forms application can be borderline impossible. I'm scared to think of what will happen with all the cloud-based stuff in the next 10 years.
>How do we separate business logic in a self-contained way that can be independent of hardware and (from a certain level) software?
I often say that there is no such thing as "business" logic. There is just logic. The least maintainable systems I've worked with were the ones with the most sophisticated attempts at abstraction.
In my opinion, the key to software longevity is making systems that allow for local reasoning, i.e. analyzing parts without knowing the whole. This can be achieved in a lot of different ways, but it needs to be a deliberate goal in system design.
But something were you can describe something like "Read this value from this field, do some math based on fields in another table, return the result"
That's why I raised the question, how do we do that over long periods of time without rewriting it in several different ways? (ASM to flat files, COBOL and JAVA to different SQL flavours, what else is next?)
And if you migrate, let's say from Oracle to MSSQL it will work for 90% of the things, for the last 10% it will be a PITA.
Seconded. Enterprise patterns mandating layers and layers of abstraction, making it incredibly hard to reason about the far flung pieces of code that actually do anything.
Cloud deployments, especially modular systems (and of course microservices) are often sold to companies as the best way to reduce technical debt. I don't think they've been around for long enough to truly test it but would be curious if a 30yr old system of microservices running in containers is easier to update than COBOL software running on a mainframe.
The nut here is that these systems evolve in a very haphazard way do to funding availability, scaling stresses, and changing requirements.
For the IRS, I think it would be useful to engage the US Digital Service to see if they could design a system based on a cluster of non-specific hardware with only network interfaces, that could host a 'tax computation engine' and a growable data store. While it is a 'big' problem, it is not as big as some of the problems I have seen hosted on 25,000 machines as a 'small' cluster. That is 800,000 cores (assuming 32 core machines) so for 140M tax payers that is 175 payers per machine. Something that could no doubt process every return in a single day, and run fraud analysis as well.
Clearly the government needs warehouse scale computers that their vendor (IBM) is not in a position (yet?) to deliver.
We can emulate pretty much any old system, but emulated "perfectly" is at best not demonstrated and at worst already proven wrong. Perfect emulation implies emulating the undocumented bugs that end up working--and there are a lot of those. Getting the correct behavior in the case of parallel components (note that this applies even to single-core systems, since dedicated hardware constructs can race with the CPU) is particularly tricky. Even without parallel issues, you can have cases where software blatantly violates the API but it works reliably and consistently, necessitating complex emulation to make it work correctly (there are some games that don't work on WINE for this reason).
Heck, even if you emulate the documented performance perfectly, you can still suffer regression behavior if the existing program just happens to rely on misbehavior of the original hardware due to less tolerant exception handling, stricter memory alignment protections, etc. in the later deployment environment.
I've seen this a lot in memory misuse / misalignment when porting between various UNIX implementations. If your development environment just happens to forgive a lot of sloppiness (cough Solaris cough), misbehavior may only show up later on other platforms.
As for the rest doing cycle exact emulation of 50 year old system is and probably always will be doable and from some PoV trivial: you can just simulate the hardware logic of the original implementation on RTL or even gate level and it still will be faster than realtime.
[Edit: "reserved for implementation" was missing from the first paragraph]
As strange as this may sound, documentation. Software is at it's core rather brittle it's designed to operate inside of a very specific system and trying to make it portable is only reasonable when you know the target ahead of time.
Fixing bugs and babysitting all day isn't going to convince people to stick around. Best you can do is get them something they can try to work with.
I wouldn't consider someone who spent 5 years on AWS, especially if they moved internally, out of date.
Whereas I've done nothing remotely close to where I want to be in about 3 years. I feel very scared about my skills, especially since I'm not even 10 years into my career.
An aside, even when you spend that long in a single position, you do need to keep learning on new and relevant technology; I attended every on house training seminar I could, which helped a lot, and spent a good portion every day reading. I spent 7 years at that company in the same effective role, and never changed job titles, but saw a >200% increase in take home pay in that same period.
To me, it's the cool-app-of-the-month-that-harvests-private-data-off-peoples-devices that is brain-killing.
Come up with programming languages with limited domain specific functionality that don't allow you to do funny machine specific things. (or even ordinary things like pointers)
Use the restricted languages for business logic and have a second language to do the plumbing.
Or just target a generic x86_64 virtual machine.
As for the hardware, I/O is done through channel programs, which can have any device as a backend - it's a generic way to do DMA.
There is a lot of legacy stuff (like CCKD, VTAM) but more or less it's all emulated today by the hardware/software.
the method by which it works is that code compiled into a new form which can be translated on the fly to match the hardware level below it.
now what is probably trapping the IRS besides a base that not everyone full understands but the sheer complexity of what they have to deal with, the tax code and whims of those in Congress.
50 years ago the IRS had to build a webserver, the servlet application code, it had to build in fault tolerance without SQS or Kafka.
If built today, the IRS' entire system would probably run on Rails with JRuby, deployed with Docker and K8s, and be 1000x more maintainable.
The system ran on a mainframe not 50 but 60 years ago. The only high level language at the time was FORTRAN, but this system was apparently written in assembly language.
Does anyone know the type of computer it ran on? The article it linked to says IBM mainframe but which model?
No direct insight to the actual system used, but FWIW IBM mainframe assembly IMHO seems 'surprisingly' user friendly due to the large amount of standard macros/routines provided, clear/direct integration with JCL, and the minimalist ethos of the OS. Take a look at some youtube videos for some examples, it actually looks like a fairly interesting/productive, if arcane, environment. Writing clean/well architected applications in it doesn't actually look like it would necessarily be a ridiculous notion.
Of course, how well any given production system was constructed and what cruft has accumulated in it over 50y is probably another story..
[1] https://www.washingtonexaminer.com/tech-timebomb-the-irs-is-...
[2] https://www.bloomberg.com/view/articles/2018-04-17/the-irs-c...
The first COBOL compiler was available 2 years later in 1960. Algol 58 wasn't available until 1960 either.
The ALGO (Algol 58) manual for the Bendix: http://www.piercefuller.com/collect/bendix/algo6008.pdf
The first compiler for PL/1 was delivered much later, in 1966.
You could have suggested LISP 1.0 but that appeared in 1960 too (as an interpreter, the first compiler was written in 1962).
LISP, COBOL, ALGOL: 1960 was a remarkable year in the history of programming languages.
Speak softly into my ear, these little lies you like to tell me.
Too many legacy migration projects fail to account for the active-active nature of migration.
How do we separate business logic in a self-contained way that can be independent of hardware and (from a certain level) software?