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
Funny you should say that. I recently wrote an Access database for a client to be run in Niambia. And it shipped about a month ago, and we've heard no complaints. Admittedly we've heard absolutely nothing from Niambia, but the management back here in England is happy about it so as far as we're conserned it's job done and onto the next project. Sometimes the client being a long way away can be a good thing :)
Of course it was in partnership with Microsoft, so perhaps they're so embarassed about how awful Access is that they didn't dare complain :)
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
Myth: Chicks don't dig geeks, no matter how much money you make. Reality: Some chicks do dig geeks (waves to gf Hi honey!), unfortunately said geek needs to make sure he looks clean and well kept. and then there's the sub-set of female geeks, which is another story entirely. (no my gf isn't a geek, but she likes geeks... all her past bfs were geeks)
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.
...since we're in the know about where indeces really start.
Myth[0] is that IT in a large organization can be effectively managed.
The fact is that users will divert away from your preplanned utopia in ways you cannot believe.
Many of those users will have their heads up their asses, having no idea how much trouble and hassle they're going to cause in the long term because they clicked on an attachment, saw a glossy magazine advertisement for software to cure all their ills, etc.
A few of those random users will actually be going in right direction, even if the corporate policy hasn't caught up to them yet.
Technically brilliant sysadmins and programmers with as much social acumen as skunk-sprayed porcupines; friendly, organized, effective managers pulling in the wrong technical direction - it's a wild wooly world in IT, not for those with weak stomachs.
"Provided by the management for your protection."
Or "the Host" as we call it. I work at a very large US Bank, and while there are all sorts of Unix machines, 1000's of Wintel boxen, anything that does anything other than file/print, ultimately involves the Mainframe. 80% of the data may not live there, since we have frames full of DB2 servers, but to get anything done, it need to go via MQ to the Host. Counting bytes doesn't necessarily mean anything - a simple Excel sheet can be > 1 Meg.
I want to delete my account but Slashdot doesn't allow it.
...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
Anybody out there ever been involved in a successful software project, much less outsourced one, where everybody was happy at the end of the day /me raises his hand
I was on a project where EVERYTHING WENT RIGHT! The hardware guys talked to us software guys to find out what we needed, they told us what was and wasn't reasonable (AND WHY!!!), delivered decent docs.
The hardware worked as advertised, the software work - port of about 250K lines of C code from Z8000 to 68K -- worked fine, and the project was finished on time and under budget, and went on to become one of the unsung success stories of the first Gulf War.
Of course, right after that, we started the project from hell. The exact opposite. Buggy hardware, buggy development tools (anyone remember the i486SL and its shitty ICE?). Project wound up being incredibly late and flaky.
The only reason we have the rights we have is that people just like us died to gain those rights. -- Cheerio Boy
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.
Hmm it's virtually the other way around here.. the MCSE is seen as so worthless that anyone who has to flash it around clearly hasn't go any real qualifications to fall back on, so they're not considered.
It didn't help the last place I worked the MCSE we hired didn't know squat about Windows, let alone general administration. I think he just kept re-taking the original the exam until he passed.
That's only because whenever the data you want *IS* recoverable you'll promptly forget that something so-close-to-tragic ever happened ;)
There is another side to that. There are some potential problems with your solution, not saying these are necessairly problems in your specific case, but these are problems I've seen:
1) Performance. Many proprietary firewalls outperform their OSS counterparts, int eh case of high end ones significantly. This is for a number of reasons, but often because it has ASICs supporting it. You can do something much faster with dedicated hardware than with software. A small, cheap, 66mhz ASIC can decode DVDs, but it takes a P3 500 to do it in software.
2) Support. When our Netscreen has problems, we can get very high level support, including having an engeneer come out if need be. With an OSS solution, you are on your own. In most cases, this doesn't matter, but if something is critical it can be the difference between an hour of down tiem and a couple days downtime.
3) Along those lines, it's much easier in the event of an emergency involving the person that supports it. Most OSS solutions I've seen are what I call "80% solutions". They do basically what you need, however they require a fair bit of reworking to do your specific job. No problem, except that means how they work is known only to you. Well, what happens if you die? This is a real question that needs to be considered in the case of critical systems. If it's a major commercial solution, no problem, the company can get support from an authorized agent that will know what they are doing while they franticly find a replacement tech guy. If it's custom OSS, they are SOL, since even a contractor is going to need time to analyze how the hell it all works to fix it.
Now I'm not trying to say that an OSS solution is never the answer. It's probably the way tto go for, say a small office firewall that is too big and complex for a simple NAT box, but not enough to need real power. However it is not the best solution in all cases.
There is also skepticism because there are a lot of poor quality OSS projects out there. There are poor quality commercial projects too, but I know that a Cisco or Netscreen firewall is good, it's been proven. I can cite thousands of big, critical networks that use them. I do not know that of the OpenBSD firewall. It does not have the legacy.
So there ARE good reasons to be skepical.
Also ironic is that the above five items are called the "Triple Constraint"
Design for Use, not Construction!