hip webinar automating integration workflow 800x100 (1)
WP_Term Object
(
    [term_id] => 151
    [name] => General
    [slug] => general
    [term_group] => 0
    [term_taxonomy_id] => 151
    [taxonomy] => category
    [description] => 
    [parent] => 0
    [count] => 441
    [filter] => raw
    [cat_ID] => 151
    [category_count] => 441
    [category_description] => 
    [cat_name] => General
    [category_nicename] => general
    [category_parent] => 0
)

More on the Practical Uses of Automation

More on the Practical Uses of Automation
by Bernard Murphy on 04-18-2016 at 12:00 pm

There’s a good article in the March issue of the Communications of the ACM which follows a theme I  commented in my “One, Two Many” post. But the CACM article has a better title: “Automation should be like Iron Man, not Ultron”.

For anyone who hasn’t seen the movies, Iron Man is a man (Tony Stark) who has built a suit to enhance his abilities. Ultron is an automaton, made in a similar form to the Iron Man suit but not requiring a human operator. Of course the CACM article doesn’t use the movie as an argument – that would be silly. What the author (Tom Limoncelli) does is to talk about different classes of automation and why one class may ultimately prove superior to the others.

The leftover principle
This is the first class – automate the easy stuff and leave the hard stuff to the humans. A problem with this is that what’s leftover gets progressively harder and within the abilities of only a small number of people. Also we develop skills to solve harder problems while we are solving easier problems. Take away the easy problems and our general problem-solving skills deteriorate. In the limit, this is the Ultron approach. There’s another problem he didn’t mention. The economics of solving easy problems are not very attractive because we don’t assign much value to solving easy problems. Of course as the problems get harder they should gain value, but difficulty is in the eye of the beholder. Ultimately this path is self-defeating because it makes obsolescent the things (us) it is supposed to be helping and even then with questionable rate of return for solution builders, at least in the early stages.

The compensatory principle
In the second class, you separate what is best done by machines (repetitive, data-driven tasks, requiring 24-7 operation, dangerous tasks, tasks requiring more than human strength or precision, …) from what is best done by humans (improvisation, flexibility, adaptability, judgment, …). Man and machine compensate for each others respective weaknesses. This should be a good guide in principle though it seems that many, perhaps most tasks do not break down so cleanly into these two categories, as is clear when you consider recent progress in vision automation. This area has seen a lot of success but progress extends less clearly to complex action consequences. Braking to avoid hitting an object is comparatively easy but if there isn’t sufficient stopping distance, choosing from the next set of options (collide anyway at lower speed, turn to avoid, thus possibly hitting something else, ..) may not always be so easy to rank-order. This path is useful case-by-case but but doesn’t provide a larger guiding philosophy.

The complementarity principle
In this final class in the article, you look at automation as a way to complement us, to extend what we can do, not a way to replace us (unless whatever you do is easily automated). In other words, automation should be more like Iron Man, not Ultron. The author brings up an interesting value for this approach, illustrated by a system he and others created to take a (hardware) system out of a cloud, send it for repair and later recommission the repaired system back into the cloud. In this case, the automation was treated as an extension to the team, working in areas it was told to work, avoiding systems it was told to leave alone and filing problem tickets where it became confused and did not know how to proceed. Over time the team learned and refined the system and were dealing with less cases manually, but never fully disengaged – they continued to learn as they refined the system and perhaps (my view) could only asymptotically move towards full automation.

For tasks on an assembly line, whether in a factory or an office, you don’t need an Iron Man, you need an Ultron. But this automation chips away only at the lower rungs of labor, as has always been the case (there really is nothing truly new under the sun). For anything higher up, we need more Iron Man suits, not more Ultrons.

You can access the CACM article HERE. Sorry you have to have a subscription or you have to buy the article.

More articles by Bernard…

Share this post via:

Comments

0 Replies to “More on the Practical Uses of Automation”

You must register or log in to view/post comments.