Slashdot Mirror
IT Myths
linuxwrangler writes "A special report in this week's InfoWorld tackles the six big myths in IT.
Among the findings: server upgrades
don't matter, 80 percent of corporate data is
not on mainframes, C[IT]Os really
do need technological savvy, most IT projects may be late or over budget but they
don't fail, IT
does scale and nearly all big shops
do run multiple platforms."
This was haning in the Programming Office where I once worked. The word was it dated from the late 70's. That you and I identify with it today says something.
A feeling of having made the same mistake before: Deja Foobar
Is "Gee, we'd like to deploy Open Source software but it would cost more for training and the changeover than a proprietary solution."
My response: "I could have built 2 redundant OpenBSD firewalls for less than half the cost of our new proprietary firewall and the OpenBSD boxes would have a faster turnaround time on security patches and PF is easier to implement and maintain than any proprietary firewall I've seen. Not to mention, just as secure if not more so"
This guy is way out there
What we need to do is to get organized and support independent regulation authorities which will prevent companies from doing anything they think its cheaper.
There is an organization in the UK, the Institute of Analyst Programmers, that bills itself as a professional organization for programmers. I am a member and every now and again I badger them about getting a royal whatever so members could qualify as Chartered Engineers (or whatever title), like the IEEE, the IMechE and so on.
Their reply? Pursuing that is not in their members best interest, as most of 'em would fail to qualify and quit, leaving the IAP without any members and hence funding. There is a rival organization, the BCS, but their chartered status is like an MCSE, no-one bothers to get it, no employer ever demands it.
Ultimately, it needs to be demonstrated to both programmers and employers that some sort of accreditation actually adds value, 'til then, it won't ever be accecpted. Face it, if a bridge collapses that matters, if the database is the wrong shade of mauve your PHB might get upset but really, who cares?
Of course embedded is different, but that's often done by EEs who can get chartered.
Maybe because MS and IBM products have a long history of working, and have large companies behind them and not .com startups whos support phone lines will be disconnected when your linux box wont boot in a year?
I've tried to push linux in the area I'm in. But, frankly, the systems we sell will probably chug along for 10 or 20 years before being replaced. They want to know that there'll be a company behind them in 10 or 20 years.
Hell, we have HP MPE running units out there that've been chugging along 10-15 years. HP is finally trying to kill off MPE, but put it on life support for another 5 or 10 years, because there's just too much stuff out there running it. In retrospect, it wasn't a bad choice, because 20 years later, HP is still around, and still going to give us another 10 years of life.
(Heh, last week I had to call HP support because our 9000 series dev machine was acting wonky. The girl on the phone had no idea they sold such stuff. I read off the model and serial number, and she goes "is that a digital camera? a printer? a laptop? can you ship it to us if I give you an RMA number?" and I was like "NO, it's an enormous ass mainframe machine that weighs about 900 tons, now send out some techs".)
Will linux be there in 10 years? Will it still be usable, or will we need to rewrite everything with each kernel release?
"We the linux kernel gurus have decided that like ipchains before it, iptables is gay and we've written a completely new tool to accomplish the exact same thing in a different way". Sure sucks if you're the poor chump supporting linux-powered gateways and routers.
Whatshisface in charge of kernel 2.6 has apparently decided that cryptoloop is "kindergarten" and is going to yank it from the *stable* kernel tree. Now, textbook perfect encryption or not, it sure sucks for people using it in production.
Just examples, I really don't have anything against linux. I just know why it's not chosen for every single task, and it's not always because "everyones a big dum-dum". Though that's certainly the case sometimes.
You need to look wayyyy down the road sometimes. That's why IBM standing behind linux is a big deal. People have faith IBM will be there in a decade. Will RedHat or Linspire be there too? Harder to say.
...like an MCSE, no-one bothers to get it, no employer ever demands it.
Then its nothing like the MCSE. Well I don't know what its like in Britain, but here it is demanded by employers, often times a candidate will not even be considered if they don't have it. On top of that, everyone and their dog gets it and the only people that recognize it has no actual value past the line on a resume, are the ones who know what they're doing.
"I use a Mac because I'm just better than you are."
> It's only a prototype - we're not going to deploy it in production.
Oh... this brings back painfull memories.
Years ago I was working at a mid-sized systems integrator (several hundred staff).
My manager told three of us to 'whip up a demo' of what a document imaging system might look like to show the company owner. So we read a few IT magazines about document imaging, and cobbled together a program WRITTEN IN A SPREADSHEET, that had three buttons:
Button 1, 'Scan', would scan an image and display it.
Button 2, 'Save', would save it to disk with a title and page number.
Button 3, 'Workflow', would throw up a spreadsheet of the documents with a column where you could enter a staff persons name.
It took us a day or two and then we showed it to the manager. He loved the concept and showed it to the owner. He loved our hot new product and showed it to sales. Sales loved our new strategic direction and showed it to clients.
A big power utility bought it for mega-bucks.
As the designers who built the thing, of course we had to install it on site and do the training.
They were expecting a full blown document imaging system with complex workflow paths etc etc.
I'm sure if any of the other guys on that team are reading this they will recognize this story at once.
- For the complete works of Shakespeare: cat
Its amazing just how little these supposed journalists truly know.
Any technology is scalable...
Really? I happen to know of a case where someone was fired because they believed this religiously; they insisted that any performance issues the new system might produce could be handled with a server upgrade.
So they upgraded the server, and what do you know - response times fell. From 300 seconds to 90. The system still wasn't usable, and the manager was fired. Perhaps the most embarassing part was the fact that a back-of-the-napkin analysis would have revealed the flaws in the "Use disk space for memory" design.
Most IT projects fail...
Well, well. This is spin at its worst. Yes, only 34% of IT projects come in on time. Another 50% are "a day late and dollar short..." - that is, after the project schedule slips, they end up shipping a product with missing features. General hint for journalist: if you have to redefine words to prove your point, you're probably not telling the truth.
No, perhaps 70% of projects aren't unmitigated failures, but I'll bet that IT projects fare far worse than other industries:
Yup, IT is still at the bottom of the barrel when it comes to delivering on promises. Not good.
The society for a thought-free internet welcomes you.