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, 22 Aug 2004

Books I mentioned

In my XP/Agile Universe keynote, I cited a bunch of books. Someone asked that I post them, so here they are.

One bit of evidence that test-driven design has crossed the chasm and is now an early-mainstream technique is JUnit Recipes, by J.B. Rainsberger. This is a second-generation book, one where he doesn't feel the need to sell test-driven design. He's content (mostly) to assume it.

I asked how it could be that Agile projects proceed "depth-first", story-by-relatively-disconnected-story, and still achieve what seems to be a unified, coherent whole from the perspective of both the users and programmers. My answer was the use of a whole slew of techniques.

At the very small, programmers are guided by simple rules like Don't Repeat Yourself. Ron Jeffries' Adventures in C# is a good example of following such rules. Martin Fowler's Refactoring is the reference work for ways to follow those rules.

At the somewhat higher level, we find certain common program structures: patterns, as described in Design Patterns. Joshua Kerievsky's new Refactoring to Patterns shows how patterns can be the targets of refactoring. You can think of patterns as "attractors" of code changes.

There are even larger-scale structures as described in Eric Evans's Domain-Driven Design, Fowler's Patterns of Enterprise Application Architecture, and Hohpe&Woolf's Enterprise Integration Patterns.

I was resolutely noncommittal about whether the larger-scale patterns can emerge from lower-level refactorings or whether pre-planning is needed. I tossed in Hunt and Thomas's The Pragmatic Programmer both because it (and they) speak to this issue and because it seems to fit somehow in the "architectural" space.

Finally, I addressed an issue that's been weighing on my mind for more than a year. Dick Gabriel has said (somewhere that I can't track down precisely) that there are two approaches to quality. The one approach is that you achieve quality by pointing out weaknesses and having them removed. The other is that you build up all parts of the work, including especially (because it's so easy to overlook) strengthening the strengths.

Testers too often take the first approach as a given. They issue bug reports, become knowledgeable discussants about the weaknesses of the product, and think they've done their job. And they're right, on a conventional project. I've decided I don't want that to be their job on an Agile project; instead, I want them to follow the second approach. I want them to apply critical thinking skills to the defense and nurturing of a growing product.

But what could that mean? How can it be done? I proposed mining the knowledge of other skilled laborers for ideas. Latour and Woolgar's Laboratory Life: the Construction of Scientific Facts describes how teams of scientists collaborate to produce their primary work product: published and widely-cited scientific papers. (I've written about that earlier.)

I mentioned another source: writers' workshops as used in the creative writing community and imported into the patterns community. Richard P. Gabriel's Writers' Workshops and the Work of Making Things is the reference work here. (See also James Coplien's online "A Pattern Language for Writers' Workshops".

## Posted at 09:13 in category /2004conferences [permalink] [top]

The purpose of a keynote

Back when I didn't give keynotes, only attended them, I thought they had two purposes. The first was to let me get near some godlike figure - your Herb Simon, your Guy Steele - and have wisdom flow from their head into mine. The second was to be inspiring.

I now realize that neither of those is to the point, though the second is closely tied up with the real purpose of the keynote, which is to provide a theme for the conference that threads through all the conversations that make it up. People should refer to the keynote in hallway talk. Other presenters should refer to the keynote's theme as they speak their piece. Questioners should ask presenters questions informed by the keynote. Collectively, the theme gets amplified and people resolve to do things about it.

## Posted at 09:13 in category /2004conferences [permalink] [top]

XP/Agile Universe 2004

I had a very good conference last week, and it seemed that everyone I talked with did too. Thinking back on it, I'm reminded of a book by Randall Collins, The Sociology of Philosophies: a Global Theory of Intellectual Change. As a teensy part of that book, he talks about how important coming together is for intellectuals and members of schools. It's from that coming together, that personal contact, that people get the emotional and creative energy to push the school forward. I'm fired up.

The local folk in Calgary did a fantastic job. They set a friendly and welcoming tone. Whatever glitches there may have been were hidden from the participants. Plus they gave me a cowboy hat.

As was announced at the Agile Development Conference, it and XP/Agile Universe will be merging next year. The united conference will be named Agile United, and it will be held in Denver.

## Posted at 07:30 in category /2004conferences [permalink] [top]