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.

tester skills

I wouldn't say better, so here it goes:


>A tester with no programming experience at all will not be able to keep up.

Keep up with what?

James Bach, Becky Fiedler and I are having an amusing time this week wrestling with bibliographic software. EndNote (Thomson) is the leading package, but it has bugs. Thomson bought out EndNote's leading two competitors a few years ago. Not surprisingly, progress in advancing the quality of the product has not been so quick.

From a bibliography management viewpoint, I think the EndNote people understand their market's needs well, but they have a multi-year history of corrupting files (including too many of my files). I suspect that their product might benefit -- A LOT -- from adding a few testers with stronger programming and debugging skills. As stands, Becky, James and I are each ready (enthusiastically ready) for a change.

So I was initially glad to see Microsoft bringing some competition to this market by adding bibliographic support to MS Word. I suspect that their software engineers in test did a fine job checking for file-corrupting bugs. On the other hand, I think this product would have benefitted enormously from serious evaluation by people who really understand how bibliography managers are used by graduate students, researchers and technical writers. In its current form, I think the product is useless for us as writers and I would not recommend it to my undergraduates when they are writing their first essays.

A tester with no programming experience will not be able to keep up with programming-related issues, but a tester with no understanding of the non-programming domains will not be able to keep up with those many aspects of the product's quality (quality = value to some person) that have nothing to do with the technical quality of the code but everything to do with whether it is worth using.

Rather than insisting that all testers be programmers or all testers be domain experts (as if any product involves just one domain), I far prefer a staffing model in which people have a variety of capabilities. Some people know code. Some people know peripherals. Some people know accounting (if that's relevant), etc. They cross-train, they pair-test, and they keep up as a team. Better a group of strong individuals than a group of mediocre generalists. And better a group of mediocre generalists than a group of programmers who know a lot of test automation and don't understand what the people who will (not) use the product will (not) use it for.

-- Cem Kaner

Pair-programming

I only tried pair-programming when I was in college, but now we do something like pair-testing, for example when someone more skilled helps another; or when we reproduce defects so the developer “watches” them happen.

Besides everything else, I think pair-working helps to keep the focus, thus saving a lot of time. I bet we won’t check new email, handle phone calls, surf the web, reply to forums like these… while we are pair-working. So we should count that as time saving, to balance the cost of having 2 workers on the same task. Due to this “’forced’ focus, we also save a lot of brain effort in context-switching.

The drawback is that, as in any focused, concentrated, demanding activity, our mind will not use the self-resting and balancing mechanisms that would work if we were alone. I would dare to say that 8 hours a day on pair-programming must harm our mental health.

Does the words meditation and silence ring any bells in this context?