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, 08 Jul 2006

The bloat trochar and the rulebook

Jeffrey Fredrick and Kevin Lawrence liked this, so I'm posting it here.

Background: On the Agile Testing list, someone wrote:

To perform surgery, you always first scrub.

Always always always. One size fits all. No exceptions. Hire a nurse whose only job is to make sure everyone does it.

Someone replied:

This statement ignores context, and its application breeds contempt not only for context but for nurses.

I was in one of those moods, so I wrote this:

I've been talking about scrubbing for surgery with my wife (who both does it, and has a grant proposal out to study something related to it). What strikes me about it is something that's been said here before about testing in Agile projects, but I think needs to be said again.

One thing about scrubbing is there is universal agreement about the goal: minimize the amount of "trash" (bacteria, etc.) that gets into the wound.

Even though, in a non-emergency, you do always always always scrub, I was surprised at how much variation there is. Some people have a rule that you scrub each of four sides of each finger ten times. Some people think you don't have to count; you just have to scrub for ten minutes. Some scrub for five. People scrub with different things. And so on.

Although the rules vary, they are rules, rather than judgment calls. People do not scrub according to today's context. They scrub the way they always scrub, which is likely the way they were taught or the way their colleagues do it. It's not really possible for them to judge context -- there's just too much noise in the causal chain from scrubbing to surgical outcome. That also makes experimental justification of scrubbing techniques hard. Still, if pressed, a surgeon could make an argument for her style in terms of the agreed-on goal.

The other thing that struck me is the degree to which the (rich) world has been constructed around the goal of sterility.

  • Being as sterile as surgeons ought to be is unnatural. Therefore, there are mechanisms in place to make it harder to give into nature. The role of scrub nurse is one such mechanism.

    Obsessive drilling in the rules is another. Because surgeons have to push in the opposite direction from what's Only Natural, strict rules are safer on average. In the way that most people think they're better-than-average drivers, most people think they're better-than-average judges of context. If they err, they'll err on the side of doing what's Natural. So you must push the pendulum a little further in the other direction, or you reduce the number of times they feel the need to make a judgment rather than follow the rule.

  • The trappings of the world are built assuming you will not be able to scrub sometimes. Field dressings don't have to be sterilized; they come that way. Ditto for instruments. Ranchers and veterinarians carry bloat trochars. If they come upon a cow with life-threatening bloat, they don't have to stab it with a pocket knife to let the gas out. Instead, they can screw in the bloat trochar. That both releases the gas and brings the stomach flush against the body wall, minimizing the trash that gets out of the stomach into the body, greatly reducing the chance of peritonitis.

    It's really impressive when you think about it: there's this vast mechanism, mobilizing the efforts of thousands upon thousands of people, all with the aim of making minimizing trash something that just happens in the expected course of things. It's like what Whitehead said about notation:

    By relieving the brain of all unnecessary work, a good notation sets it free to concentrate on more advanced problems, and in effect increases the mental power of the race.

Testing in Agile projects:

  • There is not agreement about the goal. This is repeatedly apparent in the sometimes implicit, sometimes explicit subtext of the conversations between Michael Bolton and Ron Jeffries. Michael's emotional center of gravity appears to be about finding unanticipated problems in supposedly finished work (including the work of thinking). Ron's appears to be about smoothly doing the work with confidence that the end result will be as instructed.

  • There are differing assumptions about an actor's role in the world. Michael is context-driven: understand the context and optimize your behavior within the context. Ron is goal-driven: understand the goal and change the world so that the goal is achievable and even "just happens in the expected course of things".

Those are the extremes, of course. I'm sure Michael takes advantage of opportunities to change the context, and I've seen Ron adapt to the context. However, the founding document of the context-driven school (Kaner et. al's Testing Computer Software) says, right on page vii, in bold italic font, "This book is about doing testing when your coworkers don't, won't, and don't have to follow the rules."

I switched from the context-driven approach to what I saw as a different approach because I saw Agile as making two key shifts with respect to testing:

  • Programmers are ready to follow rules they wouldn't have before because the test-first people found the trick to making those rules be of immediate benefit to programmers.

  • The change-embracing attitude of Agile largely eliminates the emotional distinction between feature and bug (replacing both with "a unit of work"). That, together with collocation and frequent releases, can make "testers are part of the team" a fact rather than a slogan.

If I am right and the debate is really about emotional comfort and personal identity, I don't expect argumentation per se will resolve it. Of the people who talk about idea change in a convincing (to me) way, only Feyerabend gives much of a role to argumentation. His Against Method is (in large part) about how Galileo argued in favor of the Copernican system in Dialogue Concerning the Two Chief World Systems. According to Feyerabend, Galileo cheated. He misrepresented the opponents' arguments, ridiculed their conclusions by surreptitiously substituting his own assumptions for theirs, studiously avoided the weaknesses behind his favored theory, and appealed to his readers' desire to hang with the cool kids.

## Posted at 12:04 in category /agile [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