Sustainable Automation

When you automate technology (at a meaningful scale, anyway), you invariably wind up writing code. I've yet to see some automation technology that was all point-and-click. Chef, Puppet, Bash, Python, Powershell.... all of them languages.

Since we're writing code for our automation, we might as well write sustainable code. I can sum up the entire point like this:

Writing code has

1. An initial cost. The cost, in time, dollars, or other measurement to write the code and 
2. A maintenance cost. The cost you incur to keep the code relevant.

If you're lucky, your code will survive long enough to accrue a maintenance cost. If that is the case, it is nearly certain that the maintenance cost will be overwhelmingly larger than the initial cost. Therefore, we always seek to reduce the maintenance cost.

Or, in more interesting terms (and I cannot take credit for this version), write your software as if it will be maintained by a homicidal maniac who knows where you sleep.

Now that we know what to do (reduce maintenance cost), we need some direction on how to do it. The answer, as is most often the case, is simplicity. How do we keep things simple?

I like to borrow a few notes from the Unix Philosophy, specifically 'keep things modular' (Small is Beautiful). Regardless of technology, you'll be modularizing your work, whether they be in functions, recipes, manifests, whatever. Think of these as your atomic work units, where the keyword here is atomic. Your units should do one thing, and they should do it well. If you want to add functionality to a unit, make another unit and have your first one call it.

Why? Why not just add functionality to the existing work units? It's easier, there are fewer units to juggle, and, yes, it takes less time.

Less time?

Less inital time, yes. But we're not working to minimize initial time. We accrue the initial time only once. The maintenance time (i.e. cost), however, we accrue every time we need to update our code. Every. Time. And god save us if we have to refactor our codebase. Forget progress, you'll be doing well just to get back to normal.

This is a quick (albeit contrived) example of my bigger point: Always strive to make things easier for the guy in the future. After all, it just may be you.