The Rules of Automation - Part I
Laziness is the mother of invention, and the driver of many an automation project. My favorite definition of Laziness is: The quality that makes you go to great effort to reduce overall energy expenditure (Larry Wall,Programming Perl, 1st edition).
There's some manual task that's been bugging you, and you know you should find a way to simplify it. You're lazy, and therefore ready to go to great lengths to automate. Keep in mind these rules to keep your automation efforts on course, espousing a relentless avoidance of unnecessary work!
Rule #1: Don't automate anything you don't thoroughly understand.
Violate this rule, and the Law of Unintended Consequences will surely strike! You can screw up without a computer. With the power of a modern computer at your fingertips, you can screw up a whole lot faster. Throw in automated processing, and you can screw up on a grand scale! My favorite example: Be extremely wary of automating failover to a hot standby machine in a High Availability configuration. You need a fault tree diagram to even attempt to comprehend all the things that might break, and plan corrective action for each. In some cases, that will mean to give up and require human intervention.
Rule #2: Don't automate a broken process.
Before you start hacking away at code to automate something, take a step back and think about the process you're about to speed up. If the process wasn't automated, it's likely the process wasn't all that well designed in the first place. First try to develop an optimal process, and then automate it.
With an open mind, think of any related processes. Should you just automate the immediate task at hand, or take a broader perspective? For example, say you're automating a software build process for your C++ code. Rather than automate just the C++ part, how about coming up with a common framework so that the "build process" for all your software products, regardless of whether they're C++, Java, or ASP, is just:
- Select Product.
- Push Button.
Rule #3: If Rule #2 causes analysis paralysis, forget it and just start prototyping!