Slashdot Mirror
Ask Slashdot: Why Won't Companies Upgrade Old Software?
An anonymous reader writes "IE6. Several governments and big companies I know use software dependent on IE6. They won't upgrade, citing the expensive cost. Do you know what's more expensive than upgrading? Downgrading to the old system they had before they upgraded! You see, before computers, companies used to have room full of people manually calculating and processing stuff. It wasn't until the computer came that they could fire all those people and save a ton of money on their collective salaries. Now, my question is: what happened to that money they saved? Even a small portion of the money saved over the years could be used to upgrade ancient systems to modern standards. However, big organizations keep citing million-dollar upgrade costs as why they won't do it. Aren't they also losing money by working with inefficient, outdated systems?"
But,OTOH, let's put it off until next quarter and let them worry about it.
Also, keeping the existing system has a 100% chance of being a nagging pain in the ass; but a pretty minimal chance of failing catastrophically in some novel way that the IT minions aren't already familiar with.
If we start development on a new system, it has a decent chance of being better; but a nonzero chance of going down in a firestorm of project-management failure, buck-passing, and overpriced Accenture code monkeys, which will make us look like total fuckups...
Uhhh...you ever actually TRY to switch over a large firm with a shitload of one off and small company software to a new OS? that shit AIN'T fun, hell I'd rather get kicked in the nuts with steel toed boots, the pain won't last as long.
It never fails, you end up with software made by companies that aren't around anymore, or those real asshole companies whose answer to everything is "shell out several thou for new licenses" (Quickbooks I'm looking at YOU) and that is IF you can buy new licenses and get the damned thing to work, you'd be surprised how many SMBs end up with "some program written by Chuck who don't work here anymore" that was only supposed to be a quick and dirty "hold us over until next quarter" but ends up becoming this mission critical house of cards that you are afraid to look at funny or it'll fall down. Then of course there is the hardware, there is nothing like having to tell middle management that all those personal printers they got for the managers have to be shitcanned because there isn't drivers for the new OS, and again that is if you are lucky and its just something like a printer,not some multi thousand dollar piece of hardware that the company doesn't support on the latest and greatest..
Now I can see giving them a browser and using GP to keep IE 6 strictly on the Intranet, that makes sense and won't give middle management a coronary when they get the bill, but all those"oh you should just upgrade" are obviously people that have never actually done a large rollout because if they had they'd know that there is NO "just" when it comes to a large business, you are talking weeks to months of slow, tedious, headache inducing work and it is NOT a pleasant experience for anybody involved. That is why I don't do corp no more, got tired of the ulcers and the headaches, not for all the tea in China would I want to do another upgrade rollout, no chance in hell.
ACs don't waste your time replying, your posts are never seen by me.
You seem to have absolutely no clue as to how real companies operate. We might have acquired 4 different apps through acquisition in a single year. And you are incredibly naive if you think an "app" just means some legacy accounting package. An "app" can be the driver package and software that runs a $120,000 electron microscope. If you really think IT is going to tell R&D to chuck their electron microscope because Microsoft isn't making enough money on the patches for the $500 PC that runs it, you might want to think of a career outside IT. Crap, we have $12,000 embossing machines that only run with DOS software.
Your attitude is what we see from recent grads with absolutely no experience. Yes, all this makes sense in a classroom, but the real world is quite messy...
Support microSD: in a post 9/11 world, it is unwise to carry your data on media that you cannot comfortably swallow.
It costs money to redevelop a system with 10 years of development. Not 10 years worth- but easily 5 years worth and that's after 3 years of having a smaller staff analyze the problem.
And the new system will lack features.
And the old system will continue to change during development despite promises to freeze it.
At my old company they had a main frame that they have declared three times now since 2000 that they would be "Off the mainframe in 12 months". I hear the latest effort just failed.
Because they do NOT want to hire the 30 programmers and pay them for 3 years to rewrite all the software. And the software is mostly ALL required and irreplaceable with packages.
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
It's thinking like that which has lead to multiple failures so far. Arrogance and overconfidence. An assumption that there is always a package or off the shelf tools which can be used.
Multiple "decent" software architects have been tilted at this particular windmill and gone down in flaming ruins.
Sometimes... very old systems have enormous amounts of business rules. There are no "off the shelf components". It's not a question of implementing a screen sort. It's a question of recognizing that given this set of data values, apply special business rule #1017 to the data. In order to do this- you have to truly understand the existing code which on mainframes can literally run to *millions* of lines of pure business logic with almost no interface code.
There is really only one way to "get off of it".
A) Build a sufficiently large team that it can develop faster than the current team developing for the platform.
B) Start redeveloping one system at a time. Do not try to "get off the mainframe".. just try to get the quarterly operating company corporate tax rollup off of the machine.
C) Iterate with the next single system until the remaining systems can be understood and then do a project to remove them.
---
The same management that has failed at this three times also set up the SAP project. 2 years of blueprinting (about half of what they needed). "Freezes" which lasted about 30 seconds before development started again. And upon discovering that they had missed 30% of the business rules- they proceeded anyway. Oh and early on they fired anyone that expressed caution very quickly so everyone else on that project got the message. Do not point out problems- keep your damn mouth shut.
It appears to be failing in a particularly spectacular fashion (even for SAP).
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.