Automation is like riding a bike

One of my new year’s resolutions was to automate a bunch of routine tasks that have been sucking up too much time and effort. Examples this time around included: moving online banking transactions into QuickBooks, synchronizing my online calendar with my cell phone, and visualizing blog subscription data. After crossing these chores off my list, I paused to reflect — as I always do after an automation binge — on the nature of software automation. It always boils down to three central themes: services, applications, and glue.

It’s easy to explain what I mean by glue. My favorite kind nowadays is Python, but Perl — the “duct tape of the Internet” — is a great choice too. Other kinds of glue include command shells, Visual Basic, and JavaScript. Defining what I mean by services and applications, and explaining how they relate to glue, is a bit harder.

Consider S1, for example — the vendor that provides online banking as a service to my local bank. My bank in turn provides me with an online banking application, by way of its Web portal. Although its managers probably don’t think in these terms, my bank also provides me with the service that I use to automate the transfer of data into QuickBooks.

This application/service duality raises an issue we’ve struggled with ever since the graphical user interface first challenged the command line: How do you strike a balance between hands-on and hands-off modes of control?

Automating software systems reminds me of teaching a kid to ride a bicycle. A hands-on phase, in which you directly control the process, segues into a hands-off phase as the kid, having internalized the skill, asserts control. During that segue, however, there’s a complex negotiation. Control is traded back and forth in varying degrees, governed by a sensitive two-way feedback mechanism.

Web software is easy to automate because there’s often a one-to-one correspondence between a hands-on action — “download transactions for these dates” — and its hands-off equivalent: the scriptable URL that expresses that action. This, for me, is the supreme benefit of the Web’s REST (Representational State Transfer) model, and the reason why I consider myself to have been a user of Web services since well before the advent of SOAP.

GUI software, on the other hand, doesn’t naturally exhibit this one-to-one correspondence between actions and statements that describe actions. Yet, it’s still achievable. Using the macro-recording features of Microsoft Office I can, for example, convert a hands-on action — “fatten the lines for each data series in the chart” — into a hands-off equivalent: the VB code that expresses that action.

Either way, what’s missing is the sensitive feedback. To automate a task I turn on the macro recorder, self-consciously perform the task, analyze it, fiddle around with the script, and then package it for reuse. So long as the context remains the same, the script will continue to work. Of course the context never does remain the same, and I’ll end up adjusting the data sources read by my account exporter and tweaking the charts created by my log visualizer.

It only takes a light touch to get the kid on the bicycle to sense and react to my cues, but I have to clobber my software to make it pay attention. Getting applications and services to share a common message bus should help. Easier said than done.