I will say (if you have that first 5-10 years of experience or so), there is real value in becoming an expert in some enterprise technology that was extremely popular 20+ years ago. The COBOL consultants getting $500 an hour right before Y2K might be an exaggeration, but you can build a career on getting businesses out of legacy systems messes.
My father is an expert on the IRS-specific IBM 360 Assembly code base and their tangled webs of attempts to get off of it, and it made for a very comfortable (and well compensated) role for the last 20 years of his career.
I would definitely not suggest COBOL or MUMPS to a 20 year old, but as a niche for a 30 year old for a stable gig? Some of these legacy systems are never going away.
> but as a niche for a 30 year old for a stable gig? Some of these legacy systems are never going away...
It's not as stable as you would think.
I have some acquaintances at JPMC and GS who have led internal initiatives to leverage foundation models to translate COBOL and other legacy software into more modern frameworks with decent success over the past 24 months.
What else couldn't be done by foundation models was then offshored to their dev teams in India, Poland, and Romania.
Hyperspecializing in a niche and ignoring other newer innovations is also setting yourself up for failure long term as of 2026.
If one cannot be bothered to deep dive into newer shifts in technology in order to both understand their pros and cons, it's hard to justify hiring them.
There is lately a lot of buzz about hiring "TENEX Engineers" so if you've got some old-school experience in TENEX, probably time to add it back in your CV!
I know a caboodle/cache admin at $dayjob, and I've never heard them mention chronicles... is it more of an internal codename than an actual function of the db?
I wish someone made something similar for Forth. Too many times I encountered something explained about forth that itself needed explanation for operators
If you are a young person, under no circumstances would I recommend that you acccept a job working with MUMPS.
You won’t be able to learn the industry best practices or the modern tools, because MUMPS predates them, and your career will suffer for it.
I will say (if you have that first 5-10 years of experience or so), there is real value in becoming an expert in some enterprise technology that was extremely popular 20+ years ago. The COBOL consultants getting $500 an hour right before Y2K might be an exaggeration, but you can build a career on getting businesses out of legacy systems messes.
My father is an expert on the IRS-specific IBM 360 Assembly code base and their tangled webs of attempts to get off of it, and it made for a very comfortable (and well compensated) role for the last 20 years of his career.
I would definitely not suggest COBOL or MUMPS to a 20 year old, but as a niche for a 30 year old for a stable gig? Some of these legacy systems are never going away.
> but as a niche for a 30 year old for a stable gig? Some of these legacy systems are never going away...
It's not as stable as you would think.
I have some acquaintances at JPMC and GS who have led internal initiatives to leverage foundation models to translate COBOL and other legacy software into more modern frameworks with decent success over the past 24 months.
What else couldn't be done by foundation models was then offshored to their dev teams in India, Poland, and Romania.
Hyperspecializing in a niche and ignoring other newer innovations is also setting yourself up for failure long term as of 2026.
If one cannot be bothered to deep dive into newer shifts in technology in order to both understand their pros and cons, it's hard to justify hiring them.
There is lately a lot of buzz about hiring "TENEX Engineers" so if you've got some old-school experience in TENEX, probably time to add it back in your CV!
https://youtu.be/6h6dhevlb0w?si=Z9RE-HHl3ovrPy8n
Is it still used at EPIC?
My understanding is that this an essential component of their "Chronicles" database system. I'd be curious to hear more recent perspectives.
I know a caboodle/cache admin at $dayjob, and I've never heard them mention chronicles... is it more of an internal codename than an actual function of the db?
Yes
primer (https://github.com/rochus-keller/MUMPS/blob/main/docs/MUMPS_...) is an interesting read
I wish someone made something similar for Forth. Too many times I encountered something explained about forth that itself needed explanation for operators
So... it looks like this was written by Claude. I am less motivated to actually read it.