In the spring of 2010, I was privileged to have a conversation with Simon Schaffer, who pointed me to the work of a sociologist and philosopher of science named Harry Collins. This year, I discovered and read Collins’ new book, Tacit and Explicit Knowledge, and a somewhat older book, The Shape of Actions (co-authored with Martin Kusch). My colleague James Bach and I believe that these books have great significance in terms of the way we understand, practice, learn, and teach the craft of testing. Three ideas in particular stand out: a distinction between two kinds of actions; a distinction between three types of tacit knowledge; and the notion of repair, whereby people fix up interactions with each other and with our media—and particularly with our machines. Today, I’ll talk about shapes of actions.
In The Shape of Actions, Collins and Kusch describe key differences between two kinds of intentional human actions that they call mimeomorphic and polimorphic. In both words, “morph” refers to shape, or form. “Mimeo-” refers to copying. (The grey-haired among us may remember that stencil printing machines used to be called mimeographs.) Mimeomorphic actions are actions that we want to do the same way every time, almost as though we were machines. Collins and Kusch use the example of a golf swing, a kind of action in which we want to eliminate variation and emphasize precision, regularity, and smoothness. “Poli-” is a pun, referring to two similar-sounding Greek roots. The Greek word polys refers to many, much, or several. The Greek polis—a different word entirely— literally means the city, so Collins and Kusch use “poli-” to emphasize the collective and diversified nature of human actions. Polimorphic actions are naturally and appropriately variable, and are rooted in social and human interactions and goals. Conversation is a canonical example of polimorphic action. Filling out a form is an example of mimeomorphic action.
Most human life and human value is centred around polimorphic actions. Still, in many actions, there’s an interplay between the mimeomorphic and the polimorphic. Shifting gears, when performed by a human driver, is something that we almost always want to do smoothly, regularly, mechanically, and (most of the time) below the level of consciousness. Indeed, the majority of North American drivers delegate the mimeomorphic action of gear shifting to mechanisms in the car itself.
Making gear shifting into a mimeomorphic action provides support for the parts of driving that are decidedly not mimeomorphic: merging into traffic, negotiating a left turn, and knowing when to break the letter of traffic laws while maintaining their spirit. Polimorphic actions are handled differently in different places, based on different social paradigms and performed for different purposes. Collins and Kusch note that in some parts of the world (Britain and North America, for example), responsibility for safety is governed by the idea of people following the rules, “violations from the rules of orderly flow being met with expressions of rage”. In Tacit and Explicit Knowledge, Collins point out that in other parts of the world (China, India), responsibility for safety is rooted in the collective, and is governed by the idea of drivers expecting the unexpected. To drivers from the West, drivers from these parts of the world drive in ways that we would consider suicidal or sociopathic. Equally surprisingly to us, people in China and India deal with this style of driving without getting upset or even remarking on it.
All this reminds me of the passage, written by Cem Kaner, in the preface of Testing Computer Software:
Some books say that if our projects are not “properly” controlled, if our written specifications are not always complete and up to date, if our code is not properly organized according to whatever methodology is fashionable, then, well, they should be. These books talk about testing when everyone else plays “by the rules.”
This book is about doing testing when your coworkers don’t, won’t and don’t have to follow the rules.
Consumer software projects are often characterized by a budget that is too small, a staff that is too small, a deadline that is too soon and which can’t be postponed for as long as it should be, and by a shared vision and a shared commitment among the developers.
The quality of a great product lies in the hands of the individuals designing, programming, testing, and documenting it, each of whom counts. Standards, specifications, committees, and change controls will not assure quality, nor do software houses rely on them to play that role. It is the commitment of the individuals to excellence, their mastery of the tools of their crafts, and their ability to work together that makes the product, not the rules.
That is: software development is a polimorphic activity, and if that’s true, testing needs to respond accordingly.
Software development involves mostly polimorphic actions, but some mimeomorphic actions help it along. Compiling a program is so much of a mimeomorphic action that these days we delegate it entirely to machines. Typing is mimeomorphic; we learn to touch-type mimeomorphically so that we can develop programs without the mechanics of typing getting in the way. Programming coaches and programming groups often mandate programmers to develop a specific style of indentation and punctuation to reduce overhead in reading and parsing code, and they mandate exercises or policies to make the regularity automatic. Even though code is designed to be run mimeomorphically, developing it, maintaining it, and interpreting it when things go wrong are all polimorphic actions.
Mimeomorphic activities tend to be easy to observe, so they tend to be easy to identify and to explicate. As a result, conversation, writing, and training in testing has tended to focus on artifacts, on documents, on procedures, and on things that can be automated—the mimeomorphic actions. Those conversations, writings, and training programs almost entirely ignore aspects of testing that are much less visible yet are far more important. This, I believe, is why so many people in our craft talk about writing test cases that are easily described as mimeomorphic actions. Those same people seem to spend little time in discussing how to test, which is composed mostly of polimorphic actions. The challenges of understanding polimorphic actions—combined with the ease of observing and describing mimeomorphic actions—explains why so many people confuse testing with checking. Those challenges explain why people credit Cucumber and its given/when/then formulas much more quickly than they credit the conversations that surround it. Those challenges explain why lowering cost by outsourcing checking work dominates the idea of increasing value by developing local testing skill. And those challenges explain why automation is often seen as some kind of silver bullet for testing problems.
Polimorphic actions are often based on tacit knowledge, different ways of valuing things, and social contexts. Collins notes that polimorphic actions
“can only be executed successfully by a person who understands the social context. Copying the visible behaviour that is the counterpart of an observed action is unlikely to reproduce the action unless it is a mimeomorphic action, because in the case of polimorphic actions, the right behavioural instantiations will change with context. Here (that is, in the book Tacit and Explicit Knowledge –MB) it will be concluded that, for now and the foreseeable future, polimorphic actions—and only polimorphic actions—remain outside the domain of the explicable, whichever of the four possible ways ‘explicable’ is defined. This has significance for the success of different kinds of machines and for the way we teach.”
Watch for a lot more discussion of polimorphic and mimeomorphic actions in the next few blog posts. Watch also for such discussion to work its way into the ways that James and I teach rapid testing.
So then mimeomorphic activities receive very little conscious attention and yet are essential to the overall result?
Michael replies: There’s more subtlety to it than that. A mimeomorphic action is one that we would like to be mechanical, machine-like. Mimeomophic actions often receive a great deal of attention as we’re learning them, but that attention tends to subside as we incorporate them (literally; in corpore means “in the body”). Consider what the mechanical apsects of driving (riding a bike, typing) were like at first: hesitant, uncertain, and subject to great conscious focus. As time went by, though, that focus relaxes because the action has become mechanical.
Seems like the only attention this behavior would receive is deviation from habit. Then, mimeomorphic actions may be easy to observe but perhaps the one performing the actions isn’t conscious of what they are doing or how they are doing it and so may have trouble describing it.
That’s something different: the distinction between explicit and tacit knowledge, which is the subject of a forthcoming post.
I certainly had this problem when trying to explain driving a stick-shift to my younger sister, to use your example. How can we be better about intentionally executing these habitual actions in a way that we can explain and justify? Doesn’t that require more attention to these actions, essentially taking attention away from the polimorphic actions that deserve more of our attention?
Not always. Tacit knowledge—stuff that we know but cannot explain or have not yet explained—can be attained through enculturation or practice. Stay tuned for more here—and better yet, read Collins’ work, too.
Thanks for writing!
Distinguishing between mimeomorphic and polimorphic actions, and distinguishing between tacit and explicit knowledge, seem to me to be at the very heart of testing. Fortunately Amazon has “look inside” applied for The Shape of Actions, so one can base one’s decision to order on quite a bit of reading, perhaps enough to obviate the need for ordering. A bugaboo of coming into a legacy project as third party tester is often the lack of access to the host company’s tribal knowledge — to my mind a fair substitute for “tacit knowledge”, in this instance — which is likely the only source of information for what an application was expected to do originally, whether the answer to that question is relevant today, where are the weaknesses in the program & its system environment, and where are the areas of functionality and interoperability that may stubbornly resist the inquiries of exploratory testing by a newbie? In The Shape of Action, Collins points out (89-90) that distinguishing between polimorphic and mimeomorphic is a skill that we may have developed in understanding human behavior, but we will be disappointed if we apply the same skill to behaviors that can or cannot be replaced by machines _without_loss_.
A big question for software & its testers is how closely can we approximate those processes which, at one point in our self-knowledge, we call “tacit” but which, through experiment and analysis, we later acquire depth of understanding and facility of RE-application. I’m thinking now of books like “Out of our Heads”(Alva Noe, not Rolling Stones) and “Self Comes to Mind” (Antonio Damasio). We think we are doing one thing (that is impossible to simulate in a test model) when we are actually doing something else (that IS possible to simulate).
Thanks again Michael for stimulating inquiries into areas that explode the often unnecessary focus of testing by the book (& by accepted heuristic).
I would say, as a Chinese driver, I’m not dealing with this style of driving without getting upset. In fact, I’m upset all the time. I feel angry and frustrated at those people who don’t behave according to rules. And there are so many not-obeying-rules people! But I do feel it is natural for each driver taking the responsibility of security.
Could you please explain more about this:”This, I believe, is why so many people in our craft talk about writing test cases that are easily described as mimeomorphic actions. ” I think designing and writing test cases are polimorphic actions.
By the way, I do get some idea through listening Simon Schaffer’s CBC radio program and reading J. M. Weinberg’s General System Thinking. Thanks for your recommendations, Michael.
[…] Michael Bolton has produced some compelling arguments against standards. I’d urge you to familarise yourself with them. See Michael’s 2011 presentation (PDF, opens in new window), and his blog. […]
[…] more on that topic I HIGHLY recommend Michael Bolton’s writing and the excellent book he introduced to me by Harry […]
[…] Test Strategy Model (1996) Von Bertalanffy, Ludwig, General System Theory (1968) Bolton, Michael. Shapes of Actions (2011) De Bono, Edward. Six Thinking Hats (1985) Collins, Harry. Tacit and Explicit Knowledge […]
[…] You will still leave gaps of things you didn’t consider. Maybe put more emphasize on the polimorphic actions that are hard to automate. Oh, and you can’t do that with Cucumber or […]
[…] recognize what can and cannot be encoded in a script or other artifacts. He distinguished between behaviour (the observable, describable aspects of an activity) and actions (behaviours with intentio… (which had inspired James’ distinction between sapient and non-sapient testing). He untangled the […]
[…] recognize what can and cannot be encoded in a script or other artifacts. He distinguished between behaviour (the observable, describable aspects of an activity) and actions (behaviours with intentio… (which had inspired James’ distinction between sapient and non-sapient testing). He untangled the […]
[…] in a manner that could, in principle, be automated. In the parlance of philosophers, checking is a mimeomorphic activity; testing is polimorphic. Some people, mainly programmers who don’t study testing much, are strongly attached to […]
[…] Filozófiai értelemben az ellen?rzés mimeomorf, míg a tesztelés polimorf tevékenység. (Mimeo- a másolásra, míg a -morf a formára, alakra utal, vagyis olyan tevékenységre, amelyet mi….) Néhányan, f?leg a programozók közül, akik nem sokat tanultak a tesztelésr?l er?sen az […]