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]

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.




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

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


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



Agile Alliance Logo