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."

Comments

Yay

[Mawbid]

So, no need to read the article, then?

Re:Yay

[killjoe]

" So, no need to read the article, then?"

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.

Ha ha, that's a good one

[krog]

IT does scale

I got a big fat 503 Service Error that says you're wrong about this one!

Re:Ha ha, that's a good one

[Marxist Hacker 42]

And I've got a slow, slashdotted Infoworld server to throw into the pot!

Other IT Myths

[ackthpt]

Myth: You will make so much money babes will be hanging off of you.
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

[trybywrench]

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.
that is now hanging up in my cube. bless you.

Re:Other IT Myths

[ackthpt]

that is now hanging up in my cube. bless you.

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.

Re:Other IT Myths

[thanasakis]

Quite correct. Would you also agree that one of the root causes of all these is that the profession is quite young. And because IMHO the situation is and will be relatively volatile in the following years, we have phenomena like these.
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

[sql*kitten]

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.

Re:Other IT Myths

[0racle]

...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.

Re:Other IT Myths

[Everleet]

guys who can hold a conversation. Not many people can do that better than a geek

*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

[Tony Hoyle]

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.

Re:Other IT Myths

[nathanh]

Ouch. That struck a nerve. Everyone who's seen companies hire Junior incompetents over Senior Engineers, raise your hand.

I sense a great disturbance in the force. As if millions of hands raised in unison.

Never trust these glossy magazine articles...

[Anonymous Coward]

... they are usually pusing something on behalf of their advertisers.

Mixed enterprise environments

[revscat]

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

[Bingo Foo]

With a name like "Nick Burns," he'll never be CEO of Gillette....

Oh God my eyes!

[Anonymous Coward]

Non-babyshit color scheme.

Now, anyone that feels like calling me a karma whore is an idiot. I posted this AC. Eat it.

Server upgrades _do_ matter

[ianbnet]

At least in some cases.

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

[stratjakt]

Well hotswapping disks is a feature of a RAID server, I wouldn't call that "upgrading".

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.

Outsourcing

[guyjr]

What about "outsourcing doesn't work", at least when it comes to software development projects.

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

[Anonymous Coward]

I saw an outsourcing project succeed. I was working for a company developing financial software. Against the advice of most of his staff, a senior manager outsourced a critical product to a firm in India. The product ended up being about six months late and cost the company several million dollars. It was also completely unusable. It was scraped and a new version was developed internally. But, by that time it had missed the market window. Though it was deployed, it was eventually withdrawn from the market.

So, how was it a success? The senior manager was sacked.

Re:Outsourcing

[metlin]

Hmm, outsourcing works depending on what is it that you do, and who is it that you outsource to.

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

[stratjakt]

All my experiences with outsourcing was with outsourcing the QA and testing.

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

[red floyd]

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.

Re:The biggest Myth is ....

[qmchenry]

Woah! You typed IT!
No! I typed IT!
Aargh! I typed IT again!
Aaarrrrgghh.. run awaaaay..

Multiple platforms?

[NoMoreNicksLeft]

Of course, nearly everywhere I've worked has been a mix of 98, NT and 2000, not to mention 2000 Pro and 2000 Server variety all out the yinyang.

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?

[ianbnet]

It seems like /. is the place to find out... if so, someone should write 'em and let them know ;)

Re:_Did_ anyone ever get fired for buying IBM?

[ackthpt]

It seems like /. is the place to find out... if so, someone should write 'em and let them know ;)

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 health, trying to make a bad choice look good.

I can't even remember all the times I nearly told someone off, with a lot of colorful language, in a meeting and quit. I do know at least once I was about a heartbeat from it and I still don't know why I didn't say what so desperately needed to be said.

Re:_Did_ anyone ever get fired for buying IBM?

[Anonymous Coward]

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.

Re:_Did_ anyone ever get fired for buying IBM?

[dbIII]

You need to look wayyyy down the road sometimes

Way down the road you'll still have access to the current source code - just like there is with the big iron. Remember, Microsoft almost poineered the poorly documented hidden API closed source operating system - before them you mostly paid for hardware and support and got the software thrown in for the price.

Will RedHat or Linspire be there too?

They won't have to be.

Myth seven

[Rev.LoveJoy]

Reading slashdot helps me at my job, because it's about technology. And ... stuff.

-- RLJ

Myths?

[Icarus1919]

These don't sound like myths so much as they sound like uneducated things that ignorant, non IT people say.

Many projects don't fail, they rust in place

[Anonymous Coward]

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

[AKAImBatman]

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.

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:

[Savet Hegar]

Your opinion matters to the one who authorizes purchases.

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!

Multiple platforms

[WD_40]

Last week I realized the error of my ways in running all one platform, therefore I took an old PC and installed DOS 6.2 and Windows 1.0 on it. I think the only way I could have gotten weirder looks from cow-irkers would be to find and install a copy of MS BOB.

myth 7

[5m477m4n]

Company technicians are not grouchy, they do not put down those idiots in accounting who can't seem to open email attachments, and they're always happy to serve their fellow employees.
Now fucking go away I'm reading slashdot.

Re:myth 7

[AnonymousComrade]

The problem here is rather those in accounting who always open email attachments, preferrably those ending in .exe or .com .

Slashdot IT myth...

[FerretFrottage]

New color scheme looks great.

No, that's a different myth.

[sulli]

"Server Upgrades Don't Matter"

Re:No, that's a different myth.

[sql*kitten]

How about "fluorescent beige is a great colour scheme"?

Another myth

[rlp]

It's only a prototype - we're not going to deploy it in production.

Re:Another myth

[hoggoth]

> 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.

Server Upgrades

[ElForesto]

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

[jstrain]

Our server can survive a slashdotting...

What about...

[deutschemonte]

the boss's hair is not always pointy?

Myth: IT Journalists Never Run Out Of Ideas...

[Kazoo the Clown]

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

[Swamii]

Slashdotters do RTFA.

One I've been seeing lately

[LittleLebowskiUrbanA]

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"

Even worse

[ackthpt]

Your opinion matters to the one who authorizes purchases.

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*

Another prevalent IT myth

[Little Grey]

You can't do real work on a Mac

they missed one... Re:Yay

[swschrad]

namely,

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:More IT Myths

[Aerog]

I'm sure your girlfriend is a very nice person, but the girl I dated who "liked geeks" ended up "replacing geeks" as often as Mozilla milestones. Unfortunately, she did this without first EOL'ing the previous version, or announcing that there was a new version.

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

Let's Start with Myth[0]

[4of12]

...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

[xsupergr0verx]

This one was repeated all through high school.

You will make a zillion dollars and be the boss.

If I could find a job, I could test that myth.

Re:More IT Myths

[JAD lifter]

My thoughts exactly. Chances are, any so-called geek that has a girlfriend is way too pussywhipped to engage any longer in true geekdom.

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 seem quite as hardcore.

In the worst scenerios, it's when a geek gets a GF and starts acting better than all of his former friends. Like when you ask him to come over on friday night to hang out in the parents basement and play AD&D and he gets all snooty and says "Heh! I've got a giiirrrlfriend now. I can't hang out with yooouuu guys on friday. I have to take my giirrlfriend to the movies." Fucking fuckwitted scumfucks.

Myth 7: IT Journalists know the field...

[gillbates]

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:

• How many unfinished bridges do you know of?
• How many unfinished housing projects can you name?
• How many unfinished/incomplete decks and swimming pools have you seen?
• How many times do EE's scrap a project after a successful prototype has been built, due to project management failure?
• How many automobile engine projects have failed? The last I can remember is Chevrolet's Vega engine - glass lined cylinders should have been a tip-off right there....

Yup, IT is still at the bottom of the barrel when it comes to delivering on promises. Not good.

Re:More IT Myths

[Tongo]

And you would do the exact same thing the first time you got laid...

for future reference

[geekoid]

this is how it should go:

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. ;)

Yet more myths

[JohnCC]

The IT industry is picking up. (I hear this from recruitment consultants) It's usually the same job posted three times a week for a month.

Your IT job is secure (until they can find a cheaper replacement).

Googles going to make you rich.

nah, but be sure to check out the related links...

[pHDNgell]

• the six big myths in IT
• don't
• not
• do
• don't
• does
• do
• More stories
• Also by michael

Assumptions about IT staff

[fuzzybunny]

So:

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.

Well

[Sycraft-fu]

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.

Failure to Plan = Planning to Fail

[unfortunateson]

According to the Project Management Institute (PMI)(of which I'm a member but not quite yet certified as a Project Management Professional) failure is any condition that isn't planned for, or approved through change control, including:

• Cost -- took more money than planned for
  
• Time -- took longer than planned for
  
• Quality -- product is not of the planned quality
  
• Scope -- project does not match planned scope which includes situations where additional features were added . The PMI considers this "gold plating" and a failure on the part of the project manager to keep the project within scope.
  
• Customer Satisfaction

Also ironic is that the above five items are called the "Triple Constraint"

Re:More IT Myths

[maxpublic]

Every geek that I've known who gets a girlfriend seems to stop being a geek after that

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

[JAD lifter]

And one day, when *you* get laid, you'll see why it is we prefer chicks to computers

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

[SageMusings]

Hey Stud,

Everyone has been talking about sex with a partner. Sorry for the confusion, sport.

Re:More IT Myths

[CaptainBaz]

+5 Insightful?

I don't know whether to laugh or cry...

Disagree

[Spazmania]

I can only work from my own experience, but:

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.