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!

Least likely

[qmchenry]

Least likely upgrades... Replacing functioning hard drives

Hmm.. unless their most likely upgrade is replacing the F1 key on their keyboard..

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

[AKAImBatman]

The real difference is that this mechanism is in place to prevent companies from hiring younger inexperienced engineers just to cut costs.

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

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

[cmstremi]

I think it's probably from Murphy's Law.

Close. Al Gore.

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

[vsprintf]

Phase 7: Promotion of nonparticipants.

In our company, phase 7 is awards for the managers.

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

[mdfst13]

Most IT professionals are hired by PHBs, not other IT professionals. Yes, IT professionals know that an MCSE is worthless. The problem is that PHBs do not. In government jobs, a certification is almost a requirement.

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.

Re:Other IT Myths

[vsprintf]

Point taken, but when you're in an auditorium, and the principal manager of a death march is given an award for documenting the *lessons learned* (which are all related to incompetent or untrained IT staff), it's even worse than seeing him promoted. Sometimes I wonder why IT people don't go postal.

Re:Other IT Myths

[maxpublic]

Most women (not girls) are atracted to guys who can hold a conversation.

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

[danharan]

I started learning basic 20 years ago at age 9. I liked it but I loved piano and politics.

Three and a half years ago, I got back into programming with PHP, and what a difference that makes (I had to laugh when I saw a one-line loop). Moved on to Java, SQL (Oracle, MySQL), and now Python.

One of the surprising things I found after getting a Java certification was how useful it was. I was getting faster at coding, not looking up things in the javadocs as often. And being forced to memorize parts of the core libraries -even if I promptly forgot half of it- means I know exactly where to look, and I won't waste time writing util classes for stuff that already exists. I've actually erased hundreds of lines at a time of code that was duplicating core lib. functionalities... :(

I don't disagree with your main point- given a choice between a person that likes to think like a programmer and a person with a certificate, I'd choose the programmer. However if you can find people that like programming and have solid knowledge in one area, do consider it a bonus :)

Re:Other IT Myths

[arose]

talk about X new feature in X new product. Whine about the government and patient laws, and have a house that could act as a tour for the history of the pc

All good traits in people of either gender.

Re:Other IT Myths

[vsprintf]

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'll be producing almost (or more) as much as your beloved senior developers

That's incorrect in a situation that requires institutional memory. I'd guess it would take 3-4 years, by which time training the developer would have negated any supposed cost savings, and the new developer would now be senior and making a much larger salary. OJT by MIS-management.

I generalize, of course, but I have experience of exactly this situation in a team of developers that I manage. Yes, I said "manage". Get over it. I'm your PHB. Kneel before me!!!!

You've already demonstrated your MIS-conception of the issue - no need to overdo it.

Re:Other IT Myths

[goon]

'... members could qualify as Chartered Engineers (or whatever title), like the IEEE, the IMechE ...'

could the qualification/licensing have to do with legal requirements under law?

• You need permits to build bridges (CE)
• 
  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. Licensing is the result of saftey requirements enfoced by legislation. Hence the guarded professions: EE, ME, CE, MD, MS, pilots, plumbers etc where a measurable standard must be met.

Until then software design going to be the lowest price, fastest turn around: not necessarily with the highest quality or safety in mind. Read this post to see what I mean.

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.

Re:Server upgrades _do_ matter

[red floyd]

P4 Xeon servers because the box says they make the internet faster,

But they do! Those cute little aliens in the commercials proved it!

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

[The Bungi]

Well, it depends on the situation I suppose. I've seen projects that were outsourced and everyone let go, only to be re-hired later (as contractors, at half the rate) to bring it under control and the outsourcing company let go.

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

[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

[ecrips]

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.

Funny you should say that. I recently wrote an Access database for a client to be run in Niambia. And it shipped about a month ago, and we've heard no complaints. Admittedly we've heard absolutely nothing from Niambia, but the management back here in England is happy about it so as far as we're conserned it's job done and onto the next project. Sometimes the client being a long way away can be a good thing :)

Of course it was in partnership with Microsoft, so perhaps they're so embarassed about how awful Access is that they didn't dare complain :)

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?

[AKAImBatman]

I know a second hand account. Apparently, a competitor of a company I worked for tended to be a bit impatient with their MIS Vice President. So they'd hire a new one, see no results in a short time, then fire him. Rinse and repeat. One of the VPs attempted a conversion to 100% IBM. He was sacked for his efforts.

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

Re:Myth seven

[pete-classic]

Not just stuff, stuff that matters.

-Peter

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

[metlin]

Agreed - but blaming it entirely on the developers is wrong, too.

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 down on your neck demanding that you wrap things up as soon as you can. So what do you do? You write sphagetti code.

The unfortunate thing here is that the customer himself is unsure of what is needed, so that uncertainty filters down to the developers, who code it up to the best of their abilities - into what they construe are the requirements.

The scar runs deep, unfortunately.

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!

Re:No...the biggest myth is:

[vsprintf]

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, it works quite well.

Boss: I know we can improve the system by leveraging the superior talent used by commercial software companies and using COTS software because I read it in a magazine, and I want everyone to know I knew it first. It will also save us tons of money.

IT: It will be a huge, costly, time-consuming project to replace our working system with COTS and integrate all the interconnected systems.

Boss: Send out an RFP, and I'll be watching this project closely since you've made your opposition known. If it fails, I'll know why.

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

Re:No, that's a different myth.

[Uber Banker]

Try This.

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"

Re:One I've been seeing lately

[LittleLebowskiUrbanA]

Like hell it is when when I can get redundancy (read failover) for less than half the price.

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.

More IT Myths

[fullmetal55]

Myth: Chicks don't dig geeks, no matter how much money you make. Reality: Some chicks do dig geeks (waves to gf Hi honey!), unfortunately said geek needs to make sure he looks clean and well kept. and then there's the sub-set of female geeks, which is another story entirely. (no my gf isn't a geek, but she likes geeks... all her past bfs were geeks)

Re:More IT Myths

[JAD lifter]

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

[slave 6742]

(no my gf isn't a geek, but she likes geeks... all her past bfs were geeks)

So, which bf upgrade are you?

I think I am version 5.0.

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

Re:More IT Myths

[bladesjester]

Been there. Done that. It's really not any fun. Could be the reason I really haven't dated in quite a while. I've gotten plenty of offers, but haven't really taken any of them up on it. *shrugs*

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.

Re:More IT Myths

[Tongo]

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

Re:More IT Myths

[Kreigaffe]

"With that attitude, it doesn't surprise me at all that you get psychos for GFs. No sane self-respecting intelligent woman, geek or otherwise, would date somebody that regarded them as naturally "crazy" or otherwise inferior." You just listed 3 qualities that I have never seen combined in the same woman :O buuuutt seriously. be glad we're calling it "crazy". In a guy, the same things would have him labeled either "idiot" or "jackass" that get a woman labeled just.. "crazy".

Re:More IT Myths

[bladesjester]

"Uuuuhhh... you realize that this either means you're gay or a cross-dresser, right?"

From your comment, I'd say you've never been in that sort of situation. It's not uncommon for the b/f's or g/f's of models to be given clothes that they like as well since the models get to keep some of the things that they like. It helps them not look *ahem* out of place (ie she is dressed really well and you're not).

Re:More IT Myths

[nyseal]

Women have that effect on ALL men (homosexuals exempt); geek or not. However, in the immortal words of Sam Kinison: "It's either that or suck a big dick; thanks God....thanks for the big menu down here!"

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

[maxpublic]

Chicks may dig geeks, but they are also chicks, and thus not to be trusted

Spoken like a true virgin.

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

[Anonymous Coward]

I'm perfectly sane, I have a great deal of self-respect (which is why I won't date a guy that isn't interested in me as an equal, and yes, that does mean that I prefer to pay my half or for him), I have an IQ over 170 and a bachelor's from Berkeley.

You know, you could have just said you're a lesbian.

Re:More IT Myths

[CaptainBaz]

+5 Insightful?

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

Re:More IT Myths

[drsquare]

That's why relationships are a bad idea. It's best to stick to temporary partners, that way you get all of the sex (and a greater variety of it) without the pointless hassle of a relationship. The women prefer it as well (even if they don't admit it).

Another Myth

[ReadParse]

Slashdotting doesn't punish your site

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:they missed one... Re:Yay

[Anonymous Coward]

That's only because whenever the data you want *IS* recoverable you'll promptly forget that something so-close-to-tragic ever happened ;)

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.

Its all about the Mainframe

[Gothmolly]

Or "the Host" as we call it. I work at a very large US Bank, and while there are all sorts of Unix machines, 1000's of Wintel boxen, anything that does anything other than file/print, ultimately involves the Mainframe. 80% of the data may not live there, since we have frames full of DB2 servers, but to get anything done, it need to go via MQ to the Host. Counting bytes doesn't necessarily mean anything - a simple Excel sheet can be > 1 Meg.

Re:the most pointless "article" ever?

[erik_flannestad]

>these are the dullest IT myths ever. where is "Goatse man dead!"?

Or "IT came from outer space"?

Unions do this already...

[zogger]

Do an IT union instead of just "an organization". They establish their own credentials,which are, apprentice, journeyman, master. Then you negotiate from a position of strength in numbers as well. You get cred from your peers, and the PHB class has to deal with it, make 'em eat it. Any "workers" organization that isn't a union is just a lobbying effort, one that will never have the cash resources of the industry organizations, a union though, is an entity they HAVE to deal with if it's strong enough and you are smart enough, and isn't the point in being an IT guy being "smart enough"?

And you also have the benefit of a solid century plus in hindsight to see what to do and what not to do with your union. You can look at the past, see where unions have been doofus tards, and where they have been strong and useful, both for themselves and for society in general, then, use your collective brains and "do it better".

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:Myth 7: IT Journalists know the field...

[pHDNgell]

How many times do EE's scrap a project after a successful prototype has been built, due to project management failure?

I've seen some incredibly cool products that, um, didn't come out of Apple.

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

The real reality

[Brandybuck]

Reality: Don't pay extra for upgradability; you'll never need it - "When was the last time you swapped out the processors on a production server? Have you ever ripped out a working system's RAID controller and substituted one with bigger cache? How about pulling out a machine's mirrored 18GB Ultra160 SCSI boot drives just to replace them with some 36GB Ultra360 spindles?">/em>

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

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

Myth #7

[Excelsior]

To research this myth, I contacted all the tier-one server manufactures. Not one would formally cooperate when asked for statistics regarding enhancements to their servers, either by sales of upgrade parts or through calls made by their field-service teams.

Maybe they had work to do with all the business from people upgrading.

Some said the data wasn't available.

Oh, a conspiracy! Or perhaps it was because the data wasn't available.

Others said it was proprietary information that couldn't be released for competitive reasons. All claimed to find the question surprising -- and were interested in reading the results.

Fortunately, one vendor, who shall remain nameless,

Ah yes, the nameless vendor. Can we say red flag?

forwarded the informal comments of a marketing manager, whose name was removed from the e-mail.

Informal comments of a marketing manager? Are you serious?

There you have it. InfoWorld has debunked a myth using the informal comments of a nameless marketing manager from a nameless vendor from some unknown date and time at an unknown location.

Myth #7: That a company whose revenue is based on page-views and number of magazines sold is more credible than a tabloid.

urban legends?

[Anonymous Coward]

From the article:

Urban legends run amok in the technology world

This guy doesn't know what an urban legend is, does he? If someone told you that an old mainframe serviceman actually got stuck inside an IBM mainframe for several days and survived by eating the spare tractor-feed paper thingies from the printer, that'd be an urban legend. But "buying a server that's can be upgraded is beneficial" is not an urban legend. It's a misconception or even just a lack of expertise.

Re:urban legends?

[a24061]

If someone told you that an old mainframe serviceman actually got stuck inside an IBM mainframe for several days and survived by eating the spare tractor-feed paper thingies from the printer, that'd be an urban legend.

Hey, that really happened to a friend of a friend!

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

On-time projects

[SlashingComments]

If you work on a financial Market data company all data feed related projects will end on-time. This is an interesting field where the deadline is set by the Stock Exchanges all over the world, so programmers tend to be very sharp and practical.

However, in my experience, writing code is about 20-30% of a project, 30% or more on RFP/Contracts/legal/Capital allocation stuff, 40% installation, hardware, comms lines etc. etc.

But end of the day, we in the financial market data business, have to deliver things on time--not before, not after.

And, yes we have been using programmers from all differnet places on the same project to take advantage of the local language/environment and the time difference.

I admit that most of my programmers don't last long ...

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.

Myth 3

[Wile_E_Peyote]

So why even put Myth 3 in there if it isn't a myth?

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"

Myth no. 0

[tcgroat]

People prefer going back to the main page to find the link to the next part of the article, instead of having the obvious "next" button.

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.

Here's something to retrain your CIO/CTO

[Phatmanotoo]

I recently came across this book, Business Information Technology. It is right on the spot, targeted at those CTOs with poor scientific or technical backgrounds. Highly recommended.