Today, many IT middle and upper management positions are staffed with folks who are technological dinosaurs (the last time they coded was in Basic at highschool, before they stepped out of comp-sci classes when they didn't quite grasp the concept of pointers). Their cluelessness then opens the doors for semi-educated people in the lower ranks, who spent 10 years at college campus playing multiuser dungeon games or others who just went through the federal employment offices' "Becoming a webdesigner in four weeks"-training.
Especially in large corporations this kind of host/parasite-relation happens quite frequently. Some of the species you might encounter:
Here we talk about folks who spend most of their time building application frameworks, that no one on this planet asked for. But that doesn't really matter - the astronaut's goal is to play around with technology, not to produce a valuable product. And without any actual application depending on the framework, there is also no need to maintain backward compatibility, so all the old programming interfaces can be thrown over board each time the astronaut wants to try something new.
Those people just unload all the latest tech terms on their CEOs, who in change will surrender to the piper's technical superiority. Truth is, the piper has no clue either, most of all he has no practical experience, and he also won't bother to consider the project requirements, as this might make his favorite technology look inappropriate (which it is, of course).
They will re-invent the wheel, and write their own database engines, XML-parsers and workflow systems - briefly everything that has been done before by more qualified people, as long as they don't have to work on their real task, namely implementing application logic. My favorite example: proprietary object/relational mappers - right, after all there are no commercial or open source O/R mappers out there, so the only way is to ramp it up on their own.
Some real-life experiences:
- The consultant who used webservices in every scenario (even for downloading binary data), and designed all of them with the same method signature (input: string, output: string). So much about "service-oriented architecture".
- The integration specialist who parsed huge XML chunks by applying DOM (which loads the whole XML structure into one big in-memory tree), instead of SAX (which is stream-oriented / event-triggered). Of course he found out too late (after deployment on the production servers), so he recommended to split large input-files into several smaller ones each time.
- The self-proclaimed Java architect, who wasted his customer's money by implementing his own (erroneous) HTTP-protocol and XML-parser (which of course exist already as part of the JDK), and managed to deliver a Java application which was not able to handle unicode.
- The programmer who explained that Visual Basic 6 had garbage collection (hint: that's reference counting, not garbage collection, dude).
- The webdesigner who insisted that the casing of his filenames were not important on a Solaris webserver (yes, he came from the Windows world).
- The guy who hand-coded his XSD- and WSDL-files, disregarding the actual implementation, or even broke XML schema syntax rules. Design by (service) contract, anybody?
A cobbler should stick to his last. I don't pretend to know about networking, so I will not tell our network folks how to configure our routers. And that's why MCSEs should not design software architecture, webdesigners had better leave their hands off enterprise application integration, why Visual Basic programmers can't just switch over to Embedded C++ in a week, and why college hackers might better not single-handedly build up the corporate system infrastructure.
If you want more proof, have a look at The Daily WTF - Curious Perversions In Information Technology. Those things happen each day (believe me, I have seen it) - at a software company close to you.