Exploration Through Example

Example-driven development, Agile testing, context-driven testing, Agile programming, Ruby, and other things of interest to Brian Marick
191.8 167.2 186.2 183.6 184.0 183.2 184.6

Sat, 07 Feb 2004

All pairs of parameters

Interesting note from Tim van Tongeren:

Based on this information we can determine: Of the 383 medical devices recalled by the FDA between 1983 and 1997, 106 (27.6%) of the bugs could have been caught by testing all pairs of parameter settings.

## Posted at 14:54 in category /testing [permalink] [top]

Mangle: What the book's about

[In this blog category, I'll be explaining my understanding of Andrew Pickering's The Mangle of Practice, toward the end of helping me think through a paper.]

The book is about how practice - doing things - causes change to happen in science and technology.

When you do things, you do things to things. You tweak, twiddle, or frob them. Pickering is concerned with a wide range of "the made things of science", a category that includes machines and instruments, scientific facts and theories, skills, social relations, rules of evidence, and so on. Part of his point is that scientists who do things put every thing in science up for grabs, up for revision. For example, one response to a line of enquiry that isn't fitting the rules is to change the rules. (Echoes of Feyerabend here.)

Pickering claims that you can see a regular pattern in the change of science. People start with some goal - to create another "made thing", be it a mathematical theory or a bubble chamber. They model their goal after some existing made thing. A theory of the three-dimensional correspondence between algebra and geometry is modeled on the existing two-dimensional correspondence. The bubble chamber is modeled on the cloud chamber.

In the course of moving toward the goal, people encounter resistance. It's not just people pushing at the world (broadly construed); it's the world pushing back. That sounds pretty trivial, but Pickering is asking us to take Kent Beck seriously when he says (as he does in Smalltalk Best Practice Patterns), "Since the code seems to be telling us to do this, let's try it." (p. 3)

Resistance is accommodated by adjusting any of the made things available. Sometimes the accommodations work; sometimes they don't. You have to keep on trying. Here's a picture I drew of how change happens. The big blob is the made things you start from. The little blobs are tentative extensions. They keep hitting resistance, in the form of the T shapes. The blobs change color to show that the extensions are flexible - they are not where you were planning on going when you started. The final location is a funny shape to suggest that you should expect to get somewhere unexpected.

Pickering emphasizes the role of chance, the degree to which your choices are dictated by the specific resistances you encounter. Those resistances are not predictable in advance. This undercuts the feeling of the inevitable progress of science; it gives more of a role for the accidents of history. For example, Pickering allows for a chemistry as competent as ours - as capable of doing things in the world - that never happened to come up with the periodic table of the elements.

That's a pretty scary notion when it comes to science. Can it be the periodic table isn't real? It's interesting that I read an article in Science News about some specialist (geophysicist, I think) who'd created a completely different periodic table. Elements appear in more than one place, for example, because that makes sense for his field. One could get into long arguments about which of the two tables is more true to nature, but I'm not gonna. One could speculate that a world in which geophysics was more important than chemistry would have invented his table first and maybe never bothered with Mendeleev's - but I'm not gonna do that either.

I'm not going to because I'm a crass pragmatist, mostly interested in building software and in the evolution of agile methods. For software projects, chance and history so clearly play a role that you won't get embroiled in the equivalent of the science wars for saying "the feature set of Microsoft Word was not inevitable". I even hope that, in my paper, I'll be able to say that the composition of Extreme Programming isn't inevitable - that its state today depends on chance happenings at Xerox PARC, Tektronix, University of Oregon, Chrysler, and Ward Cunningham's office (where one day he decided to make a wiki).

So when does this process of change stop? When do you say you have a bubble chamber, quaternions, the periodic table of the elements, the methodology called Extreme Programming? It changes when good enough associations are made between distinct made things in the culture. "Good enough" means those things serve to stabilize each other. For example, in Morpurgo's search for free quarks, he worked until he had a machine that produced consistent effects, and he could explain those effects with a theory of how the machine worked, and the effects supported one of two theories about free quarks. His changing machine, his changing theory of apparatus, and a preexisting theory of quarks hung together.

(For a related take on how change stops, see actor network theory.)

## Posted at 10:59 in category /mangle [permalink] [top]

About Brian Marick
I consult mainly on Agile software development, with a special focus on how testing fits in.

Contact me here: marick@exampler.com.




Agile Testing Directions
Tests and examples
Technology-facing programmer support
Business-facing team support
Business-facing product critiques
Technology-facing product critiques
Testers on agile projects

Permalink to this list


Working your way out of the automated GUI testing tarpit
  1. Three ways of writing the same test
  2. A test should deduce its setup path
  3. Convert the suite one failure at a time
  4. You should be able to get to any page in one step
  5. Extract fast tests about single pages
  6. Link checking without clicking on links
  7. Workflow tests remain GUI tests
Permalink to this list


Design-Driven Test-Driven Design
Creating a test
Making it (barely) run
Views and presenters appear
Hooking up the real GUI


Popular Articles
A roadmap for testing on an agile project: When consulting on testing in Agile projects, I like to call this plan "what I'm biased toward."

Tacit knowledge: Experts often have no theory of their work. They simply perform skillfully.

Process and personality: Every article on methodology implicitly begins "Let's talk about me."


Related Weblogs

Wayne Allen
James Bach
Laurent Bossavit
William Caputo
Mike Clark
Rachel Davies
Esther Derby
Michael Feathers
Developer Testing
Chad Fowler
Martin Fowler
Alan Francis
Elisabeth Hendrickson
Grig Gheorghiu
Andy Hunt
Ben Hyde
Ron Jeffries
Jonathan Kohl
Dave Liebreich
Jeff Patton
Bret Pettichord
Hiring Johanna Rothman
Managing Johanna Rothman
Kevin Rutherford
Christian Sepulveda
James Shore
Jeff Sutherland
Pragmatic Dave Thomas
Glenn Vanderburg
Greg Vaughn
Eugene Wallingford
Jim Weirich


Where to Find Me

Software Practice Advancement


All of 2006
All of 2005
All of 2004
All of 2003



Agile Alliance Logo