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

Tue, 16 Mar 2004

Meta-agility, oh my

As I write, I've bogged down on a paper I was going to submit to OOPSLA Onward! Its hook was talk about ontologies, a term I've semi-literately borrowed from philosophy. An ontology is an inventory of the kinds of things that actually exist, and (often) of the kinds of relations that can exist between those things. Everyone's got one. I abusively extended the term to make ontologies active, to make them drive people's actions.

Consider, for example, what I'll call the agile ontology. That ontology believes that software can be soft. Given the right practices, social organizations, workspace organization, and tools, software and the team that works on it can be trained to accept changing requirements. That contrasts with what I'll call the software engineering ontology, which holds that it is in the nature of software to devolve into a Big Ball of Mud. In the SE ontology, entropy is an inevitable and looming part of the world. In the agile ontology, entropy is avoidable, not central.

Then I was going to say that ontologies are important for two reasons. First, they work. They are self-fulfilling prophecies. The agile ontology constructs software and teams in a way that makes software soft; the SE ontology constructs software in a way that makes change (on average) expensive.

Second, I was going to claim that a person's ontology is malleable. Not infinitely malleable, mind you, but an awful lot of people can be shifted from the SE ontology to an agile ontology, and vice versa. (I myself have arguably made the shift twice over 20+ years.)

Finally, I was going to descend from the Heights of Abstract Argumentation and talk about somewhat pragmatic ways to shift people's ontologies. So the whole paper was to give a way for methodologists and consultants like me to think about what they're doing and get better at doing it.

I didn't want the essay to be yet another piece about the Agile methods, but instead a general statement about methodologizing. I bogged down when I realized both of my bolded claims above are meta-agile. By saying that people's ontologies are malleable, I'm being as optimistic about people as I am about software. But many of my readers would not be. By saying that methodologies work, I'm making a social constructivist statement. I'm saying that agile ontologists can arrange their world so that what they want to be true becomes true. But a SE ontologist would think that absurd: you cannot avoid the cost-of-change curve just by "having an optimistic attitude."

So I would be preaching to the converted about how to convert the nearly converted.

The hell with it. I'm going to install Zope, do something where I can feel the bits between my toes.

## Posted at 22:06 in category /agile [permalink] [top]

Testing in the Agile Manifesto

I often joke that I was the "token tester" at the workshop that created the Manifesto for Agile Software Development. I wasn't a token, but it was clear to me that the Agile story about testing was markedly weaker than the story for programming, business relations, and management. The one exception was unit testing in XP. (And, even then, it seemed there was something different about XP's approach - that was the first time I heard Ward Cunningham say, "Maybe we shouldn't have called it 'testing'," which I suspect is true).

Things have moved along quite nicely since then, to the point where Mike Beedle (another of the Manifesto's authors) suggested last week that something about testing be added:

we have come to value...

  • Tests over requirements definition and traceability

My response was that I would prefer this:

we have come to value...

  • Explanation by example over explanation by abstraction

...or even...

we have come to value...

  • Talking and pointing over just talking

These echo my long, slow change from someone who believed abstraction was the highest calling to someone who wishes he could only be backed reluctantly into abstraction.

It also marks a shift in my institutional center of gravity. It seems silly for a tester not to leap on a chance to insert the magic letters t-e-s-t into something as influential as the Agile Manifesto. But I've long thought of testing as a service function. Back in 1997, I wrote about the testing team's motto:

We are a service organization whose job is to reduce damaging uncertainty about the perceived state of the product.

In 1998, I wrote a paper, "Working Effectively With Developers" that provoked praise from a religious fellow who told me he was pleased to hear a conference talk about the spiritual virtues of service (which I was happy to hear, though I hadn't been thinking in those terms) as well as criticism from people, less panglossian than I, who pointed out that there were scant career rewards in my approach.

So my career arc has been from the 80's, in which I thought the testers served the end users by protecting them from sloppy programmers and crazed managers; to the 90's, in which I thought the testers served the project manager (and, indirectly, the end users) by giving her information that would lead to better decisions; to today, where I think of serving the whole team (and, indirectly, the project managers and end users) by producing telling examples that cause people to learn.

But that shift toward a particular service - supporting learning - by a particular means - telling examples - has led me less and less to think of myself as having a distinct role: tester. It's not that I want to eliminate testers, but that I see greater opportunity in using and remolding testing habits in radically different ways. And there will be some discarding, too.

## Posted at 09:35 in category /agile [permalink] [top]

Not iLife, my life

My life would be ever so much better if I could type control-shift-meta-cokebottle while reading mail and have that message added to an iCal todo list such that clicking on something (the associated URL?) would bring up Mail and show the message-that-prompted-me-to-want-to-do-something. Anyone know if this is possible? Mail me. Thanks.

## Posted at 08:59 in category /mac [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