Slashdot Log In
IT Myths
Posted by
michael
on Fri Aug 20, 2004 03:30 PM
from the mything-link dept.
from the mything-link dept.
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 discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Yay (Score:5, Funny)
they missed one... Re:Yay (Score:5, Insightful)
MYTH: second tape of a backup set will always be bad.
REALITY: only the tape ahead of the data you need, and the blocks in which the data you need reside, will be unrecoverable. in any tape format.
Parent
Re:Yay (Score:5, Insightful)
There is no need to article. Not because of slashdot but because it's just a few anecdotes put together as if they mean anything.
It's a stupid fluff piece. Wake me when somebody does a decent study.
Parent
Ha ha, that's a good one (Score:5, Funny)
I got a big fat 503 Service Error that says you're wrong about this one!
No, that's a different myth. (Score:5, Funny)
Parent
Re:No, that's a different myth. (Score:5, Funny)
Parent
Re:Ha ha, that's a good one (Score:4, Funny)
Parent
Other IT Myths (Score:5, Funny)
Reality: Chicks don't dig geeks, no matter how much money you make, besides, they know you'll spend it all on computers and techy toys instead of them.
Myth: Computer wizards command respect
Reality: Once the PHB figures you can do things you'll be buried in no time with stupid, menial tasks with the same priority as critical tasks.
Myth: You'll continue learning as your employer sees it critical your skills are kept up to date and foots tuition and conference fees.
Reality: As soon as you can't do something or drop dead from exhaustion, you'll be replaced by another victim fresh out of school (or your job will go offshore for 1/10 what you cost)
Myth: Programming, constructing systems, et al are fun!
Reality: Most of the projects will be as much fun as getting a new filling at the dentist (any fun you actually have will be against company policy.)
Harsh Reality of IT Project Life Cycle
Phase 1: Uncritical acceptance.
Phase 2: Wild enthusiasm.
Phase 3: Dejected disillusionment.
Phase 4: Total confusion.
Phase 5: Search for the guilty.
Phase 6: Punishment of the innocent.
Phase 7: Promotion of nonparticipants.
Re:Other IT Myths (Score:5, Funny)
Phase 1: Uncritical acceptance.
Phase 2: Wild enthusiasm.
Phase 3: Dejected disillusionment.
Phase 4: Total confusion.
Phase 5: Search for the guilty.
Phase 6: Punishment of the innocent.
Phase 7: Promotion of nonparticipants.
that is now hanging up in my cube. bless you.
Parent
Re:Other IT Myths (Score:5, Interesting)
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.
Parent
Re:Other IT Myths (Score:5, Insightful)
In my country, a civil engineer cannot undertake major projects (like say a bridge) unless he/she has reached a certain "level" which is determined by his past projects and experience. So there is a natural flow that requires that younger engineers must start from the low and climb their way up. The real difference is that this mechanism is in place to prevent companies from hiring younger inexperienced engineers just to cut costs. And that's because there must be assurance that the bridge must be built correctly, or peoples lifes will be in danger.
As time passes and our profession becomes equally crucial in many cases, I believe that the same problem will make its appearance. 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.
Of cource, before anything else, we ourselves must take our profession seriously because it is no longer a game.
Parent
Re:Other IT Myths (Score:5, Interesting)
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.
Parent
Re:Other IT Myths (Score:5, Interesting)
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.
Parent
Re:Other IT Myths (Score:5, Funny)
I sense a great disturbance in the force. As if millions of hands raised in unison.
Parent
Re:More IT Myths (Score:5, Funny)
Chicks may dig geeks, but they are also chicks, and thus not to be trusted. The Y chromosome may be smaller, but it does a very important task in nature: preventing Crazy
Parent
Re:More IT Myths (Score:5, Insightful)
As much as it would be hard for my friends and coworkers to believe, I am not a virgin. Yes I have had sex and I still tend to prefer computers to girls.
Don't get me wrong. Given the choice between a night with a sparcstation and a night with Natalie Portman I'd choose Natalie Portman anyday. But in reality, sadly, those are not the choices.
In reality I can work my ass off trying to impress some woman and then be forced to spend at least 50% of my limited freetime doing what she wants and I also have to hang out with her idiot friends and talk to her her dumbass family members on holidays and all kinds of other equally abhorrent stuff. And why? So that I can get laid a couple times a week? I've been there and done that and it is just not worth it. I'll take computers.
Now if I could find a girl who was kinda like Marla from Fight Club, then I might change my mind about girls. The problem is that most girls are lamers and the ones who aren't are already taken or wouldn't go out with me anyways.
And the fact is you don't need a girlfriend to gat laid. Get out the Yellow Pages and look under Massage Parlour and go to the ones that have adverts reading "Asian massage" and "Full Service." It'll cost you about one C-note plus a twenty dollar tip and most of the chicks are hot.
Parent
Re:More IT Myths (Score:5, Funny)
Everyone has been talking about sex with a partner. Sorry for the confusion, sport.
Parent
Never trust these glossy magazine articles... (Score:5, Insightful)
Mixed enterprise environments (Score:5, Informative)
Where I work we run ATG Dynamo for our servlet container (Linux on staging, Solaris on production), AS/400 for our core data, SQL Server for presentation tier data, .NET for our Intranet, and until very recently a single Alpha box took care of all of our credit card processing. That little box just sat in a corner and did its job, day in, day out, taking care of thousands of requests per day, and we never had to touch it. I loved that thing.
So back on topic: Yes, large, successful systems do, in fact, use mixed systems. In fact, the only place that I have worked that used the same platform for all systems were typically smaller operations; large companies rarely are able to achieve such synchrony, and I'm not sure it's even worth the effort.
(BTW: To give you a clue who I work for, our CEO is Mr. Burns. No, really.)
Re:Mixed enterprise environments (Score:5, Funny)
Parent
Oh God my eyes! (Score:5, Funny)
Now, anyone that feels like calling me a karma whore is an idiot. I posted this AC. Eat it.
Server upgrades _do_ matter (Score:5, Insightful)
I would never buy a server based on the ease with which I could replace a processor, but for my file servers -- both dedicated NAS boxes and Windows server machines -- upgrading things like storage space is critical. Being able to expand RAID arrays, replace disks (with larger models) individually or a few at a time, etc etc...
In storage, anyway, unless you are running an extremely predictible environment, upgradeability is one of the first things I look at.
Re:Server upgrades _do_ matter (Score:5, Insightful)
I'd consider "upgrading" as far as this article is about, to be something like moving everything from Windows 2000 server to Windows 2003 for increased productivity and synnergy and reverse diagonal compatibility. (Or Slackware 9 to 10, or whatever)
Or replacing all your P3 Xeon servers with P4 Xeon servers because the box says they make the internet faster, etc.
Or any other such case where it wain't broke, but you still fixed it!
In the business world, 10% growth per annum is pretty huge. So your server needs probably keep in step with that somewhat. If your server process 1000 transactions a day now, chances are good it's going to be processing 1000 transactions a day in a year. So doubling its processing capacity every year with the latest round of tech isn't logical.
Parent
Outsourcing (Score:5, Insightful)
I've been a developer for close to 10 years now, am an expert in my field (not afraid to admit it), and of course, always have more to learn. I have never, in those 10 years, been involved in a project that was clearly specified enough, such that one could turn that project over to a team situated halfway around the world, and without much interaction on the part of management, expect a final product that even closely resembles the expectations of said managers.
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? By happy I mean the project was done, delivered, closed up, move on to the next big thing.
Re:Outsourcing (Score:5, Funny)
So, how was it a success? The senior manager was sacked.
Parent
Re:Outsourcing (Score:5, Insightful)
Often times, the outsourcing decisions are last minute spur of the moment decisions, and the management does not go into the pains of choosing a good company to do the work for you.
However, there have been several instances where outsourcing has been proven to be good, and effective -- and these are the cases when the managers have taken the pains of going to the offshore development centres and talked to the people.
And ofcourse, there have been several more instances where this has NOT been the case, but this is once again a bad management decision or a poor choice. Besides, there are several areas where outsourcing does make a lot of sense, too.
Hence, I would not blindly write off outsourcing, however I would say that there are situations and circumstances where it does not make sense.
Parent
Re:Outsourcing (Score:5, Informative)
You can give them the product, a list of parameters or check boxes, and get results back in a couple days.
All the ease of building in regression testing, without all the work. And if the indians are cheaper than the time it would take me to design and implement the unit tests, then it's win-win according to PHBs.
In general, I agree with you though.
Parent
Multiple platforms? (Score:5, Funny)
I've even seen msdos and win3.11 once in awhile. This whole antitrust thing was blown out of proportion.
_Did_ anyone ever get fired for buying IBM? (Score:4, Informative)
Myth seven (Score:5, Funny)
-- RLJ
Myths? (Score:5, Insightful)
Many projects don't fail, they rust in place (Score:5, Insightful)
most IT projects may be late or over budget but they don't fail
Yes, in my experience most projects don't "fail" in the sense that they have to be abandoned, but they do "grind to a halt" once the first round of requirements are met.
I.e. you build a new invoicing system. It meets the requirements. Your team codes like mad to meet those requirements. Success, everybody has a few beers.
Then 6 months the customer needs modifications. You look at your spaghetti code and realize you have to start over. The customer grudgingly accepts.
I would consider that first project a failure even though it met the first requirements.
(Yes here is where you can make a plug for XP or agile development, but it doesn't work for every shop).
Re:Many projects don't fail, they rust in place (Score:5, Informative)
BZZZT! Wrong answer. A good software architect holds one law above all else: "The customer doesn't actually know what they want!" This means that you need to code as defensively as possible. If it's your baby that you coded from scratch, you should be able to do a good job of this. Just make sure your systems are separated, your code is clean, and just about any new feature you can think of can be plugged in.
The part that sucks is when you inherit someone else's mess, then try to whip it into a usable system that can be adjusted to the customer's needs. While I've seen plenty of well written Open Source projects (although MOST are still crap), I have never seen even ONE existing business system that was well written from the get-go. Every last one of them ended up needing a complete overhaul to get it up to snuff. It's even worse when you have no idea what your company even does. (Eventually got that worked out, thank God.)
Parent
No...the biggest myth is: (Score:5, Funny)
IT: I suggest we go with this option because of $x, $y, and $z.
Boss: How much does it cost?
IT: Well, the cost is $X but we we won't have to upgrade for several years, and it will handle all of our needs.
Boss: What can we get for $Y?
IT: We can get a remanufactured system that barely surpasses our current system.
Boss: But it IS better than what we have...right?
IT: Well....technically....
Boss: Great, let's do that!
Even worse (Score:5, Insightful)
Even worse ...
Boss: What do you think of this? (C'mon you know damn well this question has been posed to you and you've seen these same results)
IT: It might work, but will take 112 days from initiation to the production. It will require a work force of 384 slaves, 34 slave drivers, 12 engineers, 2 turtle doves, and a partridge in a pear tree. The work will need to be managed by a command team composed of 234 bureaucrats, 2347 secretaries (at least two of whom could type), 12,256 paper shufflers, 52,469 rubber stampers, 245,193 red tape processors, and nearly one million dead trees
Boss: But, in the end it'll work, right?
IT: Well...
Boss: We're getting it anyway, I've already ordered it *BIG GRIN*
Parent
for future reference (Score:5, Insightful)
Boss: But it IS better than what we have...right?
IT: No
At this point he wonder why, and then you lay on all the negatives, no buts, howevers, or 'maybe if we's'.
Its called Social skills.
I have experienced that the statement 'Well, technically..' is never any damn good.It always gets interpeted in a manner that is positive to the listeners opinions, and not the speakers opinion.
Parent
Multiple platforms (Score:5, Funny)
myth 7 (Score:5, Funny)
Now fucking go away I'm reading slashdot.
Slashdot IT myth... (Score:5, Funny)
Another myth (Score:5, Funny)
Re:Another myth (Score:5, Interesting)
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.
Parent
Server Upgrades (Score:5, Insightful)
The article is right. The only thing we've ever upgraded on our servers is the RAM, and that's usually a stop-gap until we replace the thing. We only have one server that needs to have ample expansion room (a telephony server using custom ISA cards), and it's been with us for YEARS without hitting the cieling.
I think the only people that concern themselves with upgrading all the time are the "power users" that want the latest toys.
What about... (Score:4, Funny)
Myth: IT Journalists Never Run Out Of Ideas... (Score:5, Insightful)
Years ago, Creative Computing magazine published an article entitled "Don't Write That Program If" with a set of either obvious or otherwise lame or irrelevant reasons not to write a computer program (things like, if it already exists, if it's easier to do some other way, etc., I don't remember exactly, they were just too lame). It was clear to me at the time, that they were really reaching for things to fill the few pages that weren't ads.
I responded with an letter to the editor entitled "Don't Write That Article If" which applied similar criteria to magazine articles, all of which applied to the original article (needless to say, the editor didn't print it). About three months later, they went belly-up. A shame, as at one time they were a great magazine.
And, it's certainly true there is a glut of IT mags right now, I get at least 4 and they often have content so similar it looks like the same staff is coming up with all of them. And the number of articles worth reading has been diminishing of late...
7th Myth (Score:5, Funny)
One I've been seeing lately (Score:5, Interesting)
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"
Another prevalent IT myth (Score:4, Insightful)
Myth 7: IT Journalists know the field... (Score:5, Interesting)
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.
Assumptions about IT staff (Score:5, Insightful)
An official at Oblix concurs. "[IT personnel] like the leverage that they have by keeping it a heterogeneous environment," says Ken Sims, vice president of marketing and business development at Oblix.
The VP of Marketing and business development thinks this. An engineer who obviously knows what he's talking about.
What a complete load of crap. We saw this a year or more ago in an Economist article about IT staff wanting nothing more than to save their own jobs in the face of inevitable automation.
Repeat after me, it's nonsense. Hooey. Claptrap. Most IT personnel I know are too busy keeping things running. And yes, all big shops I know _are_ multiplatform. VMS, Windows, Solaris, HP-UX, proprietary mainframe crap, etc etc etc. You've all seen it.
I'm sorry, but this is just one example of how this article discredits itself. I hate this kind of shit--it just gives managers dangerous and wrong ideas about how the IT world works.
Re:The biggest Myth is .... (Score:4, Funny)
No! I typed IT!
Aargh! I typed IT again!
Aaarrrrgghh.. run awaaaay..
Parent