Tue, 16 Mar 2004
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.
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:
My response was that I would prefer this:
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.
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.