| HOW IT REALLY WORKS vs. WHITEPAPER vs. THE MANUFACTURER Blunt Truths about how I.T. REALLY Works |
When I'm working on something in I.T., and I need to let people know how something works, there's always THREE Ways it works...
THe way it works according to the manufacturer - Aka, the various marketing "feel good" bullshit they feed you in the industry to tell you how something is going to work if you buy their product, or even just download and use it for free. Usually this is written in a style of "An all-inclusive, self-managed, ISO standards compliant solution that utilizes the power of The Cloud and A.I. Technologies, while increasing productivity, ease of use, (and some fluff to get the bean counters to think of an increased profit on top of all that). Usually upon hearing this, you will have a bunch of pamphets. The way it works according to "whitepapers" - This is the version to sell the "nerds" on a product by answering all questions that let you know WHY it should work. Basically, it will go in depth on a tech product about the ports used, protocols used, technologies used, how they work, do they integrate with a single-sign-on system or some other product that they also want you to buy (and then give extensive technical reasons on why and how this should work). It all looks good, and is less "marketing" and more "this should work because x + x = y - z". This is usually what "by the book" types want to argue about as a reason something doesn't work, and once you have enough actual evidence provided, that's why the issue created by said product ends up on the "back burner" all of a sudden, because nobody knows. How it works in real life - Basically, you bring the product into your "environment" and now the REAL rubber hits the road. Of course, some part of functionality doesn't work. That's when the finger-pointing begins between the various factions of I.T. Software people say it's a hardware problem because their poorly-written bloatware code won't run on the "paltry hardware" being used, and then the hardware people say it's a software problem because it's "bloated code", then the network people list off a list of 1001 reasons that can be boiled down to "poor adherence" to data transfer standards, or the fact the network has some quirks due to some weirdo implementation by an absolute mad-lad of a network engineer. Here's where I come in. I take a look at the problem, first I get mad because...well....Bill Hicks vs. Marketing, then I get a bit irritated by the guy rattling off the whitepapers, and then I look at what's really going on via troubleshooting. Whats hilarious is it almost always ends up being some simple "needle in the haystack" that you won't find until it pricks you in the ass...and then you feel stupid because even the "experts" couldn't figure out where that damn needle was that caused the whole problem...and then 9/10, you put a microscope on said needle, and it's a Microsoft Windows Update (slaps forehead). THen I gather data, decide how to fix, develop a process for it to share with other techs, and then pester the OEM of the software with the issue, only to fall on deaf ears - because nobody wants to do actual work anymore it seems - and then continue dealing with said workaround until they fire all their current staff and replace them with people who just switch this set of problems out with new ones. |