I recently re-read Stafford Beer’s 1967 “Cybernetics and Management”. An overview of Cybernetics and its derivation from Operational Research; because its examples use organisations and teams, it provides immediate relevance to my work.
I re-read this because I like to understand ‘automation’ from a more historical perspective, rather than focus on it from the perspective of ’test automation’.
An Unfortunate Word
A paragraph towards the end of the book stood out:
" … Automation, in short, has turned out to be an unfortunate word, because it seems to say that there is something there to be made automatic. That is to say “automation” seems to imply that we know what to automate, which is by no means true. "
I have come to view ‘Automation’ as “an unfortunate word” and in some of my Keynotes fron 2015, I recommended avoiding the use of the ‘automation’ word altogether.
(Note from July 2020, I still recommend this)
As a word, ‘Automation’ can be interpreted as:
- a process of automating something, and
- a thing in its own right
… possibly other interpretations that I can’t think of at the moment.
Automation as a process
The process of automating something doesn’t present as many problems when communicating if I avoid the ‘automation’ word.
I could say:
“I am writing code to execute ‘path X’ through the system using the data set Y and check conditions in the set Z”
And that fairly clearly summarises my current task (if we know what ‘X’,‘Y’ and ‘Z’ refers to).
If I replace ‘automating’ with ‘automation’, then I communicate with more ambiguity:
- “I’m doing test automation” (automation as a verb)
- “I’m creating test automation for path X”, (automation as a noun)
- “I’m writing test automation” (automation as a noun)
I could say:
“I am doing test automation by writing code to execute ‘path X’ through the system using the data set Y and check conditions in the set Z”
And if I do, I probably inserted ’test automation’ as a marketing phrase because I think the listener will zone out when I start talking about the actual details of my task.
Against Automation as a Thing
We can count Things. We can cost Things.
This leads to ’test automation’ as a metric-able, ‘return on investment’-isable, management obfuscation-isable concept.
Which has a tendency to encourage work and discussions mired with red tape.
If we avoid the word ‘automation’ then we can avoid much of this.
What other words can we use?
Norbert Weiner wrote a paper called “Some Moral and Technical Consequences of Automation” where he uses the word ‘Automation’ in the title.
A good copywriting technique involves using words that your readership understands, so that they then read the next sentence in the article, and keep doing that to build an effortless flow through the article. A technique I have yet to consciously exploit.
In the body of the article itself Weiner uses words such as: program, automata, automate, automatization, strategy, machine, automatic, programming, etc.
Words which are very specific in their meaning, particularly when read in context.
Weiner avoided writing ‘Automation’.
We know what to automate
And back to Stafford Beer,:
‘automation’ seems to imply that we know what to automate, which is by no means true
The conjoint concept ’test automation’ has the issue that because it relates to ’test’ we might look at the visible portions of ’test’ and then ‘automate’ what we see or have the ‘automation’ done by the people who ’test’.
Rather than looking at the system of ’testing’ and automating to improve or change the system.
We can automate to expand our possibilities rather than simply automate existing parts of the sub-system and then work around those.
Earlier in the same book
On pages 214 to 217 Stafford Beer describes many of the problems that I see written of today as ‘Test Automation Issues’
“The machines worked very fast, and looked like replacing large numbers of clerical staff - consequently the costing exercises indicated a favourable outcome for the machine. In the event, the staff savings were normally over-estimated; and the typical picture become one of disappointed managers finding that, after very intense effort and many teething troubles, they had acquired a new procedure which was not much better than the old - and certainly not much cheaper.”
I think I’ve seen this written in terms of a ‘Test Automation’ issue.
“.. is is common nowadays that large companies boast about the *number* of computers they have… one looks in vain for accounts of the astounding new modes of control which have been made possible…”
Because ’things’ are countable. And I view having more ’things’ as better than having fewer ’things’.
“The fact is that we should not have been trapped by our cost management technique into comparing existing procedures with their possible automated replacements. Because the exiting procedures set out to solve problems which arose in a computerless world, and those problems were generated by an organisational structure designed for a computerless world.”
A Knockout Reframe
On page 217 Stafford Beer hits us with a reframe:
“How can I use the computer in my enterprise?” … the question was wrong. A better question would have been “What should my enterprise be like, now that computers exist?”
It can take experience to answer this because you may not know the possibilities that have been opened up.
But if you have conducted experiments with various tools and approaches then you can start to expand your view of how automating might help you adapt your test process the the future variety in the System of Development.
And an easy first step? Stop using the word ‘automation’.
Like most Stafford Beer books “Cybernetics And Management” tends to sell at inflated second hand prices, but you can usually find affordable copies online if you keep an eye out.
References:
