Automating processes is a powerful tool that can sometime pay huge dividends. But other times it can be a time sink
I find it does take drilling on some people, that automation is not THE answer to everything (42 is that answer 😉 I have directly encountered “That process if fully automated, therefore it is perfect and doesn’t require a closer look” even when the environment has changed such that the automation needed adjusting to accommodate the new reality. Perfection is the ideal we strive for but can never meet, and that includes the things we create, but we still get those who don’t get that concept which makes things harder than they need to be.
My early packet analysis training drilled in “Auto configuration is evil!” because of all the problems that can happen with it. This was Truth #8 from Laura Chappell of Wireshark U back when she was still at Novell. Perhaps this is a bit extreme, but facing the extremes is how we find the middle ground.
Many adherents of the current wave of automation and orchestration in virtualization circles, do stray to the extreme and need some tempering. The majority of organizations are too small (under 100 work loads, which is most of my client base) to benefit from any of the orchestration systems currently being pushed.
During Randall Munroe’s book tour for “Thing Explainer”, he described how he contemplated programming the drawing of the lines for “Tree of Life”, but stopped when he realized it would likely take him a month or more to get it right, when it would take him just a couple afternoons of doing it the “old fashioned” way which is what he then did. Clearly this is something he has to watch for regularly that he created a chart for “should I automate it”
A teaser of an example, replacing the “dot” and “at” in many posted email addresses with the appropriate characters. This is a totally automate-able exercise that some people do embrace, but when is that ever an efficient use of time and other such resources? I handily resisted, how hard did you have to fight that urge?
So for automation, only do so when appropriate.
We humans are both tool users and creatures of habit. As such we often get into habits of using certain tools for everything we think they might apply, but that can lead us to more problems along the way. The classic example is someone who only knows a hammer, so they just smash everything, which certainly doesn’t help in cleaning the dishes. Understanding the range of actions we could use a tool can lead us to damaging things we don’t want to damage. Learning the limits of a tool helps us avoid damaging what we are working on and helps guide us to finding other, more appropriate tools, i.e. don’t use the hammer for washing the dishes, use a small cloth or sponge instead.
In Information Technologies, it is even harder as there are so many different tools for us to use on a regular basis and this is where I see this become a big problem and challenge for many of us. We get from one extreme of “must reinstall it all from scratch” or “upgrade” as a solution to everything, to the other of always looking for the perfect tool for every instance of the same thing and therefor taking much longer than is needed for a task. The challenges for us is to find that happy medium of reusing known tools where every they are best suited and only hunt for other tools we are working in the greyer areas, as well as knowing when to stop using a tool because the rest of the environment has evolved such that the old tool is now a detriment.
Or as a fellow Knowledge Partner Jim Henderson put it in a forum post 2012-07-05
“Repair tools by their nature tend to run with the ‘safeties’ off. So
checks to make sure that things are clean before an operation proceeds
don’t happen, and that can leave things in an inconsistent state that
then necessitates further cleanup. ndsrepair is not intended nor
designed for day-to-day administrative tasks.
Use repair tools to repair known issues. Use diagnostic tools to
diagnose issues. Use administrative tools to perform administrative
If an administrative tool reports a problem trying to do an operation,
then use the repair tools surgically to address the problem.
Look at it another way: If you have a car that’s working fine, you
wouldn’t start the engine by whacking some part of the engine with a
mallet. Only after doing proper diagnosis and determining (for example)
that the alternator was stuck would you whack it with a mallet before
taking it to a mechanic to be serviced.”
I’ve always been the deep thinker with lots of thoughts flowing in the old wetware in varying levels of scatter and focus. This is a place where such thoughts may appear from time to time. Sometimes with long gaps in between, other times with a burst of them back to back. The best way to follow is with an RSS reader, though I believe you can also point more transient tools such as twitter to it as well. The initial WordPress offer to send tweets on my behalf asked for a tighter connection than is wise.
Initial thoughts are to use this space for my IT related posts, as I do have other spaces for the rest of my Adventures in Chaos that is life.
Beware the silent types, as that silence lulls you to a false sense of security before the surprise you. I don’t usually mean to surprise people when I walk up to them, but somehow that keeps happening.