Slashdot Mirror
UK Government Department Still Runs VME Operating System Installed In 1974
Qedward writes: The UK government's Department for Work and Pensions is on the hunt for a new £135,000-a-year CTO, with part of their annual budget of £1 billion and responsibility for DWP's "digital transformation" to oversee the migration of the department's legacy systems which are still run on Fujitsu mainframes using the VME operating system installed in 1974.
Many people are shocked that computers/systems for 20 years still run, but is says a few things:
1. That people are used to crap code that can't keep running.
2. That people are used to crap products that can't last for more than a couple of years.
If it ain't broke, why fix it? They sent man to the moon on less CPU horsepower than my Nexus 6. Voyager has been running for more than 35 years in the harshness of space.
Fight Spammers!
I am always amazed how buildings constructed thousands, or even hundreds, of years ago are still standing although often in a state of disrepair due to neglect
That's what's known as survivor bias. The only examples you see of thousand-year-old buildings are the ones that didn't fall down. The ones that collapsed within a decade are long forgotten.
A modern-day castle might survive a century whereas the castles throughout Europe remain or at least remnants of their existence survive to this day
And yet, in the village where I grew up, and near countless other villages in Britain, there was a hill with a raised mound on top, which was the only remaining evidence of the castle that stood there 900 years ago.
I am TheRaven on Soylent News
Many people are shocked that computers/systems for 20 years still run,
Only people who don't know much. It's not shocking that such a thing would happen or that hardware can be made that robust. What IS shocking is that people put systems in place without any thought whatsoever to what people might want to do 20 years later. Seriously do you REALLY think it will be efficient or practical without problems for you to use the PC you are reading this on today in 20 years? Why would it be any different for a business or government?
If it ain't broke, why fix it?
Because it probably IS broken in a multitude of ways. Just because it can get a specific job done doesn't mean it does so efficiently or without problems. I've driven a lot of beater automobiles over the years and while they usually got me from point A to point B they were unquestionably broken if a number of ways. I have PCs that are 10-15 years old here in my company doing specific jobs and they definitely have problems. Yes we still get some productive work out of them but that doesn't mean I shouldn't think about replacing them when I can.
They sent man to the moon on less CPU horsepower than my Nexus 6.
Because that is all they had at the time. Nobody would even dream of doing that way today because we have better options now. Why limit yourself to yesterday's technology if you have a choice?
Voyager has been running for more than 35 years in the harshness of space.
Which is relevant how? You're comparing a spacecraft that human eyes will never see again with a earthbound computer system that we can modify or replace any time we want.
Sorry, I'm calling complete and utter bullshit.
I've worked on enough legacy systems to know they didn't start off with some astronomical budget. They built it based on a set of requirements, coded it in house, and then it gradually expanded over many years of service.
Mainframe applications aren't sexy or glamorous, they're built on relatively simple interfaces, and slowly expand in scope over time.
They keep running because eventually they're woven into fabric of every other business process you have until they become something you can't trivially get rid of ... because every other damned thing relies on it even if it isn't obvious to the user. You end up having to replace everything
My experience with migrating from legacy apps says you'd churn out a half asses solution, which isn't compatible with the existing stuff, and which can't be made so, and which would eventually be abandoned as untenable.
You'd produce some solution which might be good if it didn't depend on throwing away every other system which touched this.
The vast majority of people who claim they could produce a functional replacement for legacy software in a short period of time have never been involved in that kind of process.
If it was easy, they'd have replaced it by now.
The problem with looking for a "track record of transitioning a large enterprise from ageing mainframe technologies to next generation web, social, mobile cloud, Big Data and deep learning technologies" is that it's a set of requirements written by idiots who don't want to replace the system, they want something completely different which will involve re-tooling everything else that touches this existing system.
Put your money where your mouth is, apply for the damned job.
Lost at C:>. Found at C.
Because, as a student, if you hit it and it breaks you did something dumb and reduce the number of units for the class to use. However, as an instructor, if he hits it and it breaks, it was due for replacement.
"Wait. Something's happening. It's opening up! My God, it's full of apricots!"
What basis do you have for the claim that we "couldn't even begin to recreate" those structures? There are certainly some ancient structures for which we haven't figured out how they were constructed with the technology available at the time, but nothing that we couldn't reproduce with today's technology.
The sticking point isn't technology—it's economics. A large portion of recent development has been around cost-effectiveness. This is why we're able to have so many more material possessions, even in the face of stagnant wages (for most classes). Of course, many (including myself) would argue that we've gone too far in this direction at the expense of durability, but that's an economic choice we've made. Look hard enough, and you can find any product that meets your durability specifications—if you're willing to pay the higher price.
That being said, I do agree with the sentiment that there is more than survivor bias at work. My house was built in 1916, and has an unusually open floor plan for its age. Lacking CAD, the builders accomplished this by massively overbuilding—the floor joists (with are already quite thick) rest on beams comprised of four 2x10's laminated together. Despite its age, this house feels more solid than just about any other wood-framed building I've been in. I have no doubt that if it were placed alongside a newly-constructed house and both left to nature, that the 99-year-old house would remain intact longer.
Well, the problem happens when some technology evangelist or manager who doesn't know a damned thing about the existing system claims it's easy to migrate it to modern tools.
And neither the customer, nor the guy saying it's easy, has the barest clue about just how many other things depend on that system, and nobody can fully enumerate the functionality and corner cases.
And then you end up trying to shoe-horn a purpose built piece of software which has ran fine for decades into a modern paradigm, and realize you are failing utterly.
Because the modern tools usually simply can't accommodate all of the rules and logic in that system. They can't be cajoled into having enough flexibility, or simply can't do the same task.
People consistently underestimate just how well these systems do their job, and just how many little corner cases and integration points have been woven into them over the years. The platform is no longer elegant, or easy to explain, but it just keeps working. But dozens of other things rely on it, and if you change the underlying thing you rebuild everything else.
I've been on several projects trying to replace stuff built in the 60's and 70's -- and I wouldn't go near another one without very loudly saying how much risk is involved. Hell, even a system which has been around only since the 90s might be non-trivial to migrate away from -- precisely because in the 90s people were still building much more purpose-specific software.
It's a catch 22 ... they get increasingly difficult to maintain, but they sometimes are impossible to replace.
As I said, if it was easy to replace these systems, it would have been done already. Discovering just how difficult this can be has been the downfall of many a naive person who claims it's an easy thing to do.
Lost at C:>. Found at C.