Survive giving a joint keynote with someone far more charismatic.

Sit down with people to work further on my design-driven test-driven design example. (I've been too busy.)

For the benefit of people considering business-facing test-driven design, find collaborators to discuss these questions:

1. In what situations is it a bad idea?

2. What groundwork needs to be laid? (For example, do you need to have programmer testing well ingrained before making the leap? Or can product-level TDD work before unit-level TDD?)

3. Anyone doing something they haven't before will hit snags surprising to them but predictable by others. For example, a beginning weightlifter might not expect progress to come in spurts separated by distressingly long plateaus. They'd be more likely to succeed if warned. What snags should new "examplers" be warned about?

Write up the results.

Talk to Eric Evans, Rick Mugridge, and others about the intersection between tests and ubiquitous language.

I sometimes think our rhetoric is too behaviorist: stimulus comes from outside the project, the project responds appropriately and also reconfigures its "circuitry" to be better at responding to such stimuli. As my foreword to the Fit book hints, I'm hung up on the notion that surprise can be internally generated - that ideas from within the project can shape the systems that "drive" it. (See Ward's story of Advancers for an example.)

If that's (a) possible and (b) desirable, we've woefully understudied the internal conditions that bring it about. There's got to be more to it than refactoring, removing duplication, etc. I'd like to provoke some conversations about what else there is. As Pasteur would have said had he been terser, "Chance favors the prepared mind." Prepared how? (Being attracted to Hutchin's notion of distributed cognition, I'm more interested in the preparation of the team, environment, and flow of events than in preparation of the individual.)