@WTFE
Spoken like someone who's never watched a dozen "modern" replacements come in at ten times budget (in both time and money) and still not actually managed to replace the system that it was intended to replace.
Spoken like someone who's never dealt with budgets (in both time and money) based on unrealistic expectations for what things should cost or how long they should take, or situations where 'not actually manage' is just code for 'awkward due to unfamiliarity'.
A decade? That's what you think is old and decrepit?
Read for comprehension, you curmudgeonly fuck. I was pretty clearly speaking about software systems built for functioning within an OS with a modern counterpart, not embedded systems probably built in the 50s.
Further, 'shit that became common 10 years ago' is not the same thing as 'a decade old makes something old and decrepit' by any reasonable standard of understanding what the fuck someone is saying, especially when speaking about technology.
In either case, examples of shit like code written before Unix was even a thing were clearly well outside the realm of what I was talking about in that quote.
I know techies love to use the latest hotness, but only a dumb businessman listens to techies breathlessly talking up their grand future vision of modern hardware and modern software. If you have a system that works and does what you need, you don't replace it. You introduce a new system iff you have clearly-identified business needs that are not being met by your existing system. And even then, you probably start by having the new system only augment what you've got until it has proven itself and can be expanded to replace.
All of which completely ignores the fact that I flat out said that what you had said was true, so why you thought you had to rehash that shit here I have no idea.
What I was talking about, and why @Shebakoby's gripe is still perfectly valid, are companies running old ass programs that are so far past no longer supported and quickly reaching the point where they aren't going to be compatible with a modern OS in any reliable way while still needing to use a modern OS for everything else. And specifically, as I already said, when there are viable modern alternatives even if they aren't perfect.
This is especially a problem when the industry you're a part of is moving forward with that modern alternative regardless of its imperfection. It doesn't really matter if what you're trying to do was best done on an original Macintosh or Windows 3.0 machine, on Version 1 of whatever program you're using, when the people you're in business with are on Windows 7 using Version 8 of whatever that program is, and those versions are incompatible due to changes in how the program works and organizes data. At some point you're going to have to suck it up and move forward.
If you've seriously, for real, in all honesty never run into one of the many examples of organizations running wildly outdated software that they can and should have moved on from, but haven't due to a combination of fearing the unfamiliarity of the new and being unwilling to pay employees to learn a new system before it gets implemented and a million other examples of them just clinging to the past 'because it works' even when it is clearly not going to keep working for much longer? Then really, you have lived a charmed fucking life.
But they do exist, and it is pretty common to run across, and it is pretty fucking frustrating. Especially when they want all the bells and whistles and advancements a modern OS provides but don't want to let go of some shit that came out the same decade as the original version of the OS.
HERE IS SOME BOLD TEXT TO INDICATE YOU SHOULD PAY CAREFUL ATTENTION TO THE FOLLOWING:
Much like I said before, everything you described is true, from the catastrophic results of trying to update embedded systems by companies more interested in showing off those bells and whistles than creating a functional replacement (they often get paid regardless), to the techheads who will want to replace everything with the most cutting edge modern version of itself even when it's not necessary or even detrimental to the process.
But what I said, and what @Shebakoby was griping about, are also true. We're just talking about different aspects of the same general issue, and none of us are wrong. Aside from the bits where you were wrong about what you quoted. 
Many of us are quite good at it!
