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

Sun, 09 Oct 2005

PNSQC annotated bibliography

In my Pacific Northwest Software Quality Conference talk, I'm going to throw out a blizzard of references. Here they are.

"The conduit metaphor: A case of frame conflict in our language about language", Michael J. Reddy, in Metaphor and Thought (2/e), Andrew Ortony (ed.)

Shows how our standard metaphor for communication is one of shipping something from one mind to another via a conduit. Many examples. I don't think that's the way communication really works, so the metaphor misleads us into thinking requirements documents are a good idea, and that the reason they so often fail is that we're not smart or dedicated enough.

Philosophy and the Mirror of Nature, Rorty

Takes apart the idea that concepts and words are direct mappings of hard-edged categories in the world. Sometimes that works. Sometimes it doesn't. Requirements documents assume that words can capture what the solution to a problem essentially is. But if that's not possible, in general...

Women, Fire, and Dangerous Things: What Categories Reveal About the Mind, Lakoff

A more empirical treatment of the same idea. Categories have fuzzy edges, partly because most lack a single defining characteristic that must be present.

Personal Knowledge: Toward a Post-critical Philosophy, Polyani

A discussion of tacit knowledge.

Refactoring, Fowler

I tell the Advancer story, which is uses the Method Object refactoring, which is described in Fowler.

Cognition in the Wild, Hutchins

I suggest the Advancer story is an example of Hutchin's distributed cognition, the notion that it sometimes doesn't make sense to say that particular people solve a problem. Instead, it's more useful to point to an assemblage of people and things as doing the thinking. So the common statement "the code is trying to tell us something" is not meaningless.

Fit for Developing Software: Framework for Integrated Tests, Mugridge and Cunningham

I use Fit tables as examples of examples.

"Soap Opera Testing", Buwalda

Soap opera tests have the same relationship to normal uses of the product as soap operas have to real life: drastically condensed and exaggerated.

Image and Logic: A Material Culture of Microphysics, Galison

Galison discusses how different groups of people collaborate on shared goals. He claims that they develop "trading languages" (like trading pidgins and creoles) to organize their work. I believe his analysis fits project teams.

Domain-Driven Design, Evans

Evans's "ubiquitous language" is an example of a Galison trading language.

"The Good, the Bad, and the Agile Customer", Alesandro, Better Software, November/December 2005.

An example of gradually tuning communication to suit both a business representative and a development team.

Situated Learning: Legitimate Peripheral Participation, Lave & Wenger

A description of how types of learning like apprenticeship work. Not an easy read. I wrote a review and summary.

How to Do Things with Words (2/e), Austin

Austin talks about "performatives", which are sentences that don't describe the world but rather do things in it. ("I now pronounce you husband and wife.") Performatives don't really fit in the "words map to categories in the world" framework.

Limited, Inc., Derrida

Derrida (I'm told) argues here that all statements are performatives. (I haven't read the book yet - I've not found Derrida to be easy reading.) That makes sense to me: we utter things to change the world. Even when I'm defining a word for my daughter, I'm changing the world inside her head.

That's where I end, having given 16 tactics for improving communication, each compatible with this nonstandard view. My ending motto is this:

As intermediaries, we do not need to send abstractions down the conduit from the business to the programmer. Anything that provokes the programmer to write the right code is fine by us.

## Posted at 09:49 in category /misc [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.

 

Syndication

 

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

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

 

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

 

Join!

Agile Alliance Logo