4 probes to a medium

Here is an enlightened post from Michael Bolton (as usual):

Marshall McLuhan talked a lot about media. A lot of people don't realize that his ideas were different from the ones that we usually associate with the words that he used. To McLuhan, a medium is anything that effects a change--a new tool or technology, an idea, a programming language, a hat... anything that appears as a new figure somewhere in an existing ground.

In order to investigate the impact or significance of a medium (or as McLuhan called it, the medium's "message"), McLuhan proposed four probes, or questions, that one could ask about a medium:
1) To what extent does this medium enhance or extend or intensify or expand or enable some human capability?
2) What previously obsolete medium (perhaps from a vastly different field or from a long time ago) does this new medium retrieve, or remind us of?
3) What existing (and perhaps ubiquitous) medium does this new medium make obsolete?
4) How might this medium reverse its intended or expected or beneficial effect when it exceeds its capacity, or when it becomes the norm? Every medium, said McLuhan, exhibits the general characteristics that the probes ask about--extension, retrieval, obsolescence, reversal. The intention is to try to look at a new or anticipated medium using these probes.

(Mark Federman (http://whatisthemessage.blogspot.com ) explains Marshall McLuhan's Laws of Media very well and very clearly; "Creating a Culture of Innovation" is the paper to look for on the right of the blog page. Even better is his book, co-authored by Derrick deKerckhove, "McLuhan for Managers", which is hard but still possible to get.)

So: the test team enhances the ability of the product team to find bugs, to report problems, to understand the product. It retrieves the idea of the test pilots, the food taster, the editor, the lab researcher. It obsolesces, at least to some degree, the field technician, the support centre, the unhappy customer. And it reverses into the developers who won't check their own code, blaming and fingerpointing, mindless confirmation of trivial test ideas, automated behaviour, product managers passing responsibility for release decisions on to the testers...

That list is after a minute or two of brainstorming; it could be much longer. What would happen if you spent 15 minutes on the with your test team, or your development team, or your managers? You might be able to set clearer goals (or limits) about what you want to extend, how you want to model the team, what or who the team might make redundant, and (at least) to anticipate and control for some of the reversal effects of the test team.

One more thing: rather than thinking about metrics, try thinking about observations that you might make. If it makes sense simply to describe the observation, do that. If it makes sense to measure the observation, remember that metrics are media too. That is, each metric you use will extend, retrieve, obsolesce, and reverse some aspect of your observation.

---Michael B.

See the sticky minds article here.