4 ms·

When you've got a system that is, for example, underpinning your whole business operation (eg billing, machine controls, whatever) and that cost thousands (ofte

When you've got a system that is, for example, underpinning your whole business operation (eg billing, machine controls, whatever) and that cost thousands (often tens or hundreds of thousands) to implement and it only works on a legacy version of an operating system (be that Win 3.11, Linux 2.4, or even just XP) you WILL move heaven and earth to avoid disrupting that system. Even if it's a smooth migration to a current release, it doesn't have 15 years of perfect history behind it. And that's when you can migrate. There are plenty of control systems for devices that cost $millions that were bought decades ago that just need to keep working. You don't have source. The vendor went out of business with the dot-com bubble. Yeah, we probably could replace all the things, but at what cost? Will it beat the last 15 years of perfect uptime? Are you the buy willing to stake your job on it? Or shall we just paper over the cracks and keep shovelling coal into that server in the corner? Edit: I'm describing worst-case scenarios in specific use-cases but even if there isn't a good reason to stay behind, the feeling of "why fix what ain't broke?" is pervasive in management, especially IT management. Maybe it's a generational thing and we'll see waves on waves of upgrades in the next decade or two but I'm fairly sure that'll just lead to another generation of "make do"ers.

pilsetnieks 11y ago
> why fix what ain't broke Because it will break eventually. That decrepit PC full of metal dust running XP that controls this here multimillion CNC mill will, given enough time, fail. Some part or other will fail, and eventually you won't be able to find new parts anymore that work with it. Granted, for an XP PC it's far in the future but still. Besides, a Win 3.11 or XP PC won't have a 15 year uptime, it will probably have a sticker on it reminding users to reboot it daily.
- abakker 11y ago
  I encountered a company with an "antique" mainframe running an "antique" COBOL workload. It had 17 YEARS of continuous uptime. Every single piece of hardware was either double or triple fault tolerant, and nearly everything had been swapped along the way, but the workload (a transaction processing system of a sort) had never ceased operations. It had never needed to be changed. I know mainframe != Win XP, but it is important to remember that in many systems, it isn't really like a car, where you do maintenance to keep it running, its more like a wrench, where you use it until it breaks, and then get another one that does the same thing. In the years that the wrench is in service, new types of steel, new ergonomics, etc. might come out, but none of that is sufficient reason for upgrade. Only the actual failure of the system justifies replacement. Sure, its rare for that to be the case in a tech company, but not so rare in a company that just uses IT to do something else.
yeukhon 11y ago
I agree and disagree. As an operation person, I think we need to make an argument for why X can't be done right away, but we must have a plan Y for migration. I know for a fact there is still some ancient database server running in our data center serving our critical business but there's a plan to migrate that to modern databases. While re implementing everything is costly, company has to hire specialist from a specific consulting firm to support such ancient database, and how long can we retain such talent without spending extreme amount and caution? "I am scared if I did this will screw everything up." There will be a point they have to migrate such database to something modern, and the cost is still several million plus. The same argument that corporate world doesn't allow Python 3 or has a hard time to migrate to Python 3 because machines are running on some ancient RHEL servers or because of some security requirement. I get it and I don't get it. First, let's ditch RHLE. Fuck that. I really don't see reason to use RHLE; fine, YMMV. But it is people's job to do work. Some pieces can die, and some pieces will have to evolve, either from scratch, or slowly. No one said software development and operation support are easy, see https://pbs.twimg.com/media/CWC74tOVAAAsls0.jpg:large https://pbs.twimg.com/media/CWC74tOVAAAsls0.jpg:large.
madaxe_again 11y ago
What's wrong with continuous improvement? Our entire ethos is that software is never finished.
- mgkimsal 11y ago
  much like "perfect is the enemy of good", one might even say "better is the enemy of 'good enough'"
- oliwarner 11y ago
  I love CI but it does only works if it's continuous. The scenarios I was describing don't lend themselves to it. It's usually vendor deployed, closed source software. Not an in-house production. That or it truly is ancient, from an era when CI wasn't a thing. You can resurrect development but as I mentioned before, this can often involve resurrecting people, not just the project. And employing them indefinitely for something that —for the past 10 years— has been free. It's a bloody hard sell to higher management. My last post wasn't my opinion. I wasn't advocating for never updating, I'm just passing along my experiences with the sorts companies that have systems they don't touch out of fear.
  - madaxe_again 11y ago
    Totally true - resurrecting a project is hard, to say the least, particularly if years have passed. We're an isv/agency hybrid, and we deploy monthly. The stack started a decade ago but it's as modern as it was then. Ultimately the onus sits with the implementers to think about maintainability, and the end-user to think in terms other than the immediate. Unfortunately, many legacy systems were implemented with the "it'll be replaced soon" view, and 30 years on are still limping along. The software we build today will, if the species survives, probably still be in use in a century or more. Think of your great-grandchildren when you go "that'll do"!

pilsetnieks 11y ago

> why fix what ain't broke Because it will break eventually. That decrepit PC full of metal dust running XP that controls this here multimillion CNC mill will, given enough time, fail. Some part or other will fail, and eventually you won't be able to find new parts anymore that work with it. Granted, for an XP PC it's far in the future but still. Besides, a Win 3.11 or XP PC won't have a 15 year uptime, it will probably have a sticker on it reminding users to reboot it daily.

abakker 11y ago
I encountered a company with an "antique" mainframe running an "antique" COBOL workload. It had 17 YEARS of continuous uptime. Every single piece of hardware was either double or triple fault tolerant, and nearly everything had been swapped along the way, but the workload (a transaction processing system of a sort) had never ceased operations. It had never needed to be changed. I know mainframe != Win XP, but it is important to remember that in many systems, it isn't really like a car, where you do maintenance to keep it running, its more like a wrench, where you use it until it breaks, and then get another one that does the same thing. In the years that the wrench is in service, new types of steel, new ergonomics, etc. might come out, but none of that is sufficient reason for upgrade. Only the actual failure of the system justifies replacement. Sure, its rare for that to be the case in a tech company, but not so rare in a company that just uses IT to do something else.

yeukhon 11y ago

I agree and disagree. As an operation person, I think we need to make an argument for why X can't be done right away, but we must have a plan Y for migration. I know for a fact there is still some ancient database server running in our data center serving our critical business but there's a plan to migrate that to modern databases. While re implementing everything is costly, company has to hire specialist from a specific consulting firm to support such ancient database, and how long can we retain such talent without spending extreme amount and caution? "I am scared if I did this will screw everything up." There will be a point they have to migrate such database to something modern, and the cost is still several million plus. The same argument that corporate world doesn't allow Python 3 or has a hard time to migrate to Python 3 because machines are running on some ancient RHEL servers or because of some security requirement. I get it and I don't get it. First, let's ditch RHLE. Fuck that. I really don't see reason to use RHLE; fine, YMMV. But it is people's job to do work. Some pieces can die, and some pieces will have to evolve, either from scratch, or slowly. No one said software development and operation support are easy, see https://pbs.twimg.com/media/CWC74tOVAAAsls0.jpg:large https://pbs.twimg.com/media/CWC74tOVAAAsls0.jpg:large.

madaxe_again 11y ago

What's wrong with continuous improvement? Our entire ethos is that software is never finished.

mgkimsal 11y ago
much like "perfect is the enemy of good", one might even say "better is the enemy of 'good enough'"
oliwarner 11y ago
I love CI but it does only works if it's continuous. The scenarios I was describing don't lend themselves to it. It's usually vendor deployed, closed source software. Not an in-house production. That or it truly is ancient, from an era when CI wasn't a thing. You can resurrect development but as I mentioned before, this can often involve resurrecting people, not just the project. And employing them indefinitely for something that —for the past 10 years— has been free. It's a bloody hard sell to higher management. My last post wasn't my opinion. I wasn't advocating for never updating, I'm just passing along my experiences with the sorts companies that have systems they don't touch out of fear.
- madaxe_again 11y ago
  Totally true - resurrecting a project is hard, to say the least, particularly if years have passed. We're an isv/agency hybrid, and we deploy monthly. The stack started a decade ago but it's as modern as it was then. Ultimately the onus sits with the implementers to think about maintainability, and the end-user to think in terms other than the immediate. Unfortunately, many legacy systems were implemented with the "it'll be replaced soon" view, and 30 years on are still limping along. The software we build today will, if the species survives, probably still be in use in a century or more. Think of your great-grandchildren when you go "that'll do"!