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

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

_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: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: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.)