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. [Full story at InfoWorld.com]
Former URL: http://weblog.infoworld.com/udell/2005/02/10.html#a1173