IT Myths 380
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."
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.
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.
nah, but be sure to check out the related links... (Score:4, Funny)
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)
Re:No, that's a different myth. (Score:5, Funny)
Re:Ha ha, that's a good one (Score:4, Funny)
Least likely (Score:2, Funny)
Hmm.. unless their most likely upgrade is replacing the F1 key on their keyboard..
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.
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.
More IT Myths (Score:2, Interesting)
Re:More IT Myths (Score:2, Funny)
Only poseurs have girlfriends.
(That line was blatently stolen and mutilated from the movie SLC Punk. I believe the original line was "only poseurs fall in love.")
Re:More IT Myths (Score:3, Funny)
Seriously. Every geek that I've known who gets a girlfriend seems to stop being a geek after that. Sure they may still work in IT or be majoring in CS or whatever. Sure they may still spend hours a day programming, reading SF and playing video games. And they probably still call themself a geek. But it is like when they get a GF something dies inside them. They no longer
Re:More IT Myths (Score:3, Insightful)
Re:More IT Myths (Score:3, Funny)
Re:More IT Myths (Score:4, Funny)
That's because they're getting laid. And one day, when *you* get laid, you'll see why it is we prefer chicks to computers.
Max
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.
Re:More IT Myths (Score:4, Insightful)
I don't know whether to laugh or cry...
Re:More IT Myths (Score:3, Informative)
Re:More IT Myths (Score:5, Funny)
Everyone has been talking about sex with a partner. Sorry for the confusion, sport.
Re:More IT Myths (Score:2, Funny)
So, which bf upgrade are you?
I think I am version 5.0.
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
Re:More IT Myths (Score:3, Funny)
Spoken like a true virgin.
Max
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.
Re:Other IT Myths (Score:3, Insightful)
Ouch. That struck a nerve. Everyone who's seen companies hire Junior incompetents over Senior Engineers, raise your hand.
Re:Other IT Myths (Score:5, Funny)
I sense a great disturbance in the force. As if millions of hands raised in unison.
Re:Other IT Myths (Score:3, Insightful)
However, often it is also the case that "senior" engineers sitting on high salaries have no incentive to try hard or achieve more. They just sit there.
Yes, there is often deadweight in the senior engineering positions, but line management has no idea who it is. The best bullshitters are considered to be the best engineers by MIS-management.
Now, young and inexperienced developers fall into 2 categories: potential, no potential. If you can find the ones with potential, then within a couple of years they
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.
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.
Re:Other IT Myths (Score:4, Interesting)
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.
Re:Other IT Myths (Score:3, Insightful)
Re:Other IT Myths (Score:3, Insightful)
could the qualification/licensing have to do with legal requirements under law?
you need to submit a license to mass produce an electrical device (EE) or vehicle (ME, AE)
release a pharmaceutical (PHC, CE)?
Until Tom dick and harry start getting injured or die as a result of coding errors I suspect this is the real reason software engineers do not require licensing.
Re:Other IT Myths (Score:3, Insightful)
Phase 7: Promotion of nonparticipants.
In our company, phase 7 is awards for the managers.
Re:Other IT Myths (Score:3, Funny)
*rolling on floor snickering*
We can hold conversations with one another (after the appropriate bonding rituals of course), but certainly not with...people...
Re:Other IT Myths (Score:3, Insightful)
A geek is no more likely to be able to hold an intelligent conversation than any other person. They just *sound* smarter because their chosen topics of conversation revolve around technical items rather than football, or cars.
Max
Re:Other IT Myths (Score:3, Funny)
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:2)
Re:Mixed enterprise environments (Score:5, Funny)
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.
Re:Server upgrades _do_ matter (Score:3, Funny)
But they do! Those cute little aliens in the commercials proved it!
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:2, Insightful)
Ultimately I guess outsourcing is about as much hit and miss as not, but with the slight difference that you probably have much more control when the project is not half a world away.
Re:Outsourcing (Score:5, Funny)
So, how was it a success? The senior manager was sacked.
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.
Re:Outsourcing (Score:2, Interesting)
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
Re:Outsourcing (Score:2)
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.
Re:Outsourcing (Score:2)
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?
Does 'Hello World!' count?
Re:Outsourcing (Score:4, Interesting)
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.
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)
Re:_Did_ anyone ever get fired for buying IBM? (Score:3, Insightful)
Catch up with the times. s/IBM/Microsoft/
The true tragedy is CIO's who think, because they've mastered Excel or Access, believe they've got a firm understanding of enterprise systems and make decisions based upon this belief. It'd be comic if it hadn't resulted in many a night's lost sleep shoring up disasters. Sometimes you've gotta leave to see how much you were suckered into sacrificing your life and
Re:_Did_ anyone ever get fired for buying IBM? (Score:4, Interesting)
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.
Re:_Did_ anyone ever get fired for buying IBM? (Score:4, Insightful)
Re:_Did_ anyone ever get fired for buying IBM? (Score:3, Funny)
Myth seven (Score:5, Funny)
-- RLJ
Re:Myth seven (Score:2, Funny)
-Peter
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:3, Insightful)
If the customer anticipates any future modifications and upgrades, I think that ought to be mentioned in the inital functional specifications, so that the developers can make sufficient room for such accomodations.
And before you say that any good developer should be able to anticipate all this and the like, it's ridiculous - just how much can you anticipate? When you do anticipate and write modular code, it takes more time - and the boss is
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.)
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*
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.
Re:No...the biggest myth is: (Score:3, Insightful)
Your opinion matters to the one who authorizes purchases.
In our company, it's more like:
Boss: Our Megabux system does not meet the organization's needs because it doesn't do X, Y, and Z.
IT: It does do all those things.
Boss: It doesn't work correctly because it does not programatically match our mission and is architectually incompatible and too tightly coupled with our other existing systems, according to my golfing partner.
IT: It meets all the design and functional requirements. In fact, i
Multiple platforms (Score:5, Funny)
myth 7 (Score:5, Funny)
Now fucking go away I'm reading slashdot.
Re:myth 7 (Score:3, Insightful)
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.
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.
Myth #7 (Score:3, Funny)
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...
Re:Myth: IT Journalists Never Run Out Of Ideas... (Score:2)
I mean "80% of corporate data is held on mainframes" isn't true because of all the data in excel spreadsheets and email? Send one email message with one excel spreadsheet to everyone on the company, and that instantly dwarfs the storage of the database you got the spreadsheet data from - but I don't think tha
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"
Well (Score:4, Interesting)
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.
Re:One I've been seeing lately (Score:3, Insightful)
Yeah, there is more to IT than firewalls. Protecting your IP/corporate resources is pretty important in my book though. Anyway, that's my example and if you don't like it, posting anonymously and bitching isn't going to do anything because I doubt anyone else will read your comment.
Another Myth (Score:3, Funny)
Another prevalent IT myth (Score:4, Insightful)
Let's Start with Myth[0] (Score:4, Interesting)
...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.
Here's the big one (Score:4, Funny)
You will make a zillion dollars and be the boss.
If I could find a job, I could test that myth.
Its all about the Mainframe (Score:3, Interesting)
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.
Re:Myth 7: IT Journalists know the field... (Score:3, Insightful)
I've seen some incredibly cool products that, um, didn't come out of Apple.
The real reality (Score:3, Insightful)
Come to think of it, we replace and upgrade the drives in our servers all the time. I'm not talking about the disposable 1U racks the mom-and-pop IT house calls "servers", but the very expensive Sun enterprise servers. When a harddrive goes out (and they do, they do) you don't replace the whole fricking server. That's stupidity of the highest magnitude.
You might not ever need to upgrade the CPU, but you do want to keep that expensive server operational and in use as long as possible. That means additional storage on occasion and replacing the parts that go bad.
Yet more myths (Score:4, Funny)
Your IT job is secure (until they can find a cheaper replacement).
Googles going to make you rich.
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.
Failure to Plan = Planning to Fail (Score:4, Interesting)
Also ironic is that the above five items are called the "Triple Constraint"
Disagree (Score:4, Insightful)
IT Myth 1: Server upgrades matter
At a nimble shop (i.e. mine) they do. Of course I don't upgrade the servers while in production. Duh! I remove them from production, upgrade them (often by mixing and matching parts), and then assign a new task. When I'm at the top of my form, the hardware goes through about three different production cycles before being retired for power or reliability reasons. Each cycle sees it in a substantially different configuration where it has to meet different requirements.
Not everybody does things this way... Some always launch a new production server with newly purchased hardware. But if they do they're spending more money than they need to.
IT Myth 4: CIOs and CTOs have a greater need for business savvy than tech expertise
Nevertheless, CIOs usually get the job because they are business savvy guys who have found a functional middle-ground with their tech-savvy underlings. They are, in other words, slightly better listeners than the average businessman.
Technical experts to not mistake CIOs for technical experts. That's left for other businessmen and journalists to do.
IT Myth 5: Most IT projects fail
Since the big corporate shift to Java, Visual Basic and dot-net, few projects fail outright anymore. The language structures themselves tend to prevent the most blatent mistakes that would otherwise require experts to fix. Of course, that allows mediocre developers to talk their way into senior positions and it leaves them every bit as mediocre when it comes to solving subtle problems. The projects often end up almost-sort-of-working (you know what I mean!) and they do get deployed. They also get replaced with another almost-sort-of-working product two years down the line after it has becomes obvious that the original software isn't making the grade.
The real difference is that a failed project in Java is marginally deployable while a failed project in C probably can't leave the shop.
Meanwhile, as something of a corollary to Paul Graham's piece about programming languages, the few projects which use another language tend to attract and group good developers who don't want to compete with the posers for senior positions. With less dispersal of the talented, those projects have a much better chance of success than they used to.
Re:The biggest Myth is .... (Score:4, Funny)
No! I typed IT!
Aargh! I typed IT again!
Aaarrrrgghh.. run awaaaay..
Re:urban legends? (Score:3, Funny)
Hey, that really happened to a friend of a friend!