Sat, 08 Jul 2006
The bloat trochar and the rulebook
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.
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
One thing about scrubbing is there is universal agreement about the
goal: minimize the amount of "trash" (bacteria, etc.) that gets into
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
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
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