EMA Blog: Business Intelligence and IT Management

An unfortunate side effect of maintaining a vibrant technology subculture is an over-reliance on acronyms to describe basic concepts and solutions. For instance, to be ITIL compliant a CTO may need to invoke the ARP of a TCP or UDP IPv6 WAN to determine the DNS entry of an SMTP server for a POS system to prevent GIGO and ensure WYSIWYG. Now, if you understood that statement, you are certainly among the lucky few “in the know” and probably use these terms on a regular basis. However, if you are unfamiliar with or had to look up any of those terms, you likely recognize the core problem. While acronyms are intended to simplify complex technical conversations, they actually impede successful communication if any participants are unaware of their meaning. Sometimes acronyms are introduced to shorten long-winded technobabble; sometimes they are developed as marketing devices to create unique sounding products; and often they evolve simply because they make techno-elitists sound more knowledgeable.

IT administrators love to write scripts – at least, the most talented ones do. Scripting provides a powerful platform to automate simple and repeatable tasks. However, like with most powerful tools, there is an overwhelming temptation for scripting to be overused. When faced with a project deadline, a high-pressure failure event, or even just the need to simplify day-to-day events, administrators can unintentionally create scripts that are so complex they actually put the business at risk. I must confess that during my 2 decades-long tenure as an IT administrator and engineer, I’ve written a lot of scripts…a LOT of scripts…and learned a lot of important lessons. Scripting was never intended to replace application programming. Its purpose is to provide a quick and easy resource for performing simple and repeatable tasks. It is not uncommon, however, for scripts to start simple but balloon over time into complex code that is virtually unintelligible even to its author.