Thu, 14 Jul 2005
What I want to accomplish at Agile 2005
Survive giving a joint keynote with
someone far more
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
In what situations is it a bad idea?
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?)
Anyone doing something they haven't before will hit snags
surprising to them but predictable by others. For example,
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
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.)
## Posted at 09:35 in category /conferences