Advanced TDD Randori and Fishbowl

room: Sheraton Hall C, LC — time: Thursday 14:00-15:30, Thursday 16:00-17:30
Average Rating: -

Audience: Agile developers who already practice test-driven development.

Based on feedback from a number of introductory TDD Randori presentations given in 2007 by Dave Nicolette and Rod Coffin, Dave and Ryan Hoegg, and Rod and Ryan individually, it seems as if most of those who show up for agile conferences, user groups, and internal corporate seminars already know the concept, the value proposition, the basic techniques, the best practices, and the available tools for test-driven development. Participants in these sessions have been asking for more depth. In particular, we have had more than a few requests for a workshop covering the application of TDD to:

  1. building up complex algorithms incrementally (e.g., computationally-intensive embedded systems, or business logic based on interdependent business rules).
  2. an existing codebase that was not written with testability in mind the first time around (legacy code).
  3. multi-step refactorings (e.g., Replace State-Altering Conditionals with State, or Replace One/Many Distinctions with Composite).

We will use Java with JUnit in an Eclipse environment for the hands-on segments.

Request for specific feedback

Between the two of us, we have not reached a consensus about whether this should be one session or two. One of us feels point #1 deserves a dedicated session, while the other does not see enough unique material here to warrant two separate sessions. We would appreciate feedback about what participants would like to do, and we can tailor the material accordingly.

We also are not sure whether this would fit better in Developer Jam or Examples. We would appreciate guidance on that, too.

Process/Mechanics

We plan to follow the randori format for the workshop segments and to run the retrospective as a fishbowl. This structure has been well-received in past presentations and seems to be a good way to maintain active participation and interest.

The randori format was developed at the Paris and Helsinki code dojos in 1995. It’s described here and here. It’s very “live” and a lot of fun. Here’s a summary, partially gleaned from Agile Finland with a few modifications:

  • There is one computer with the video output projected on a screen so all participants can see it.
  • Coding is done at the single computer by a pair of developers.
  • One half of the pair switches out every 5 or 10 minutes. We will start with 10 minutes based on experience/feedback from last year’s workshops, and change the time interval if appropriate.
  • The pair on the keyboard should continuously explain what they are doing.
  • The pair on the keyboard should stop when someone from the audience falls off the sled — and only continue when that someone is back on track again.
  • The audience should give comments on design only when there is green bar. (During red bar audience can only ask questions)
  • The pair should not continue on writing new code if other participants are not happy with the current design (The code should be always well refactored before starting to write new code)
  • The pair will use TDD (Test-Driven Development).
  • The programming language to be used is announced in advance per session. We will use Java for this session.
  • The presenter acts as a product owner.
  • There is no fixed limit on the number of attendees, since observers may at least participate in the fishbowl retrospective.

The fishbowl format has been used quite a lot, and we suspect it doesn’t require much explanation. Just in case, there’s an explanation here.

Because of the content of this particular workshop, we will have to intersperse brief explanatory presentations with the randori activities. We will keep the talking to a minimum; just enough to set up the programming challenges for the randori segments. Also, one of us will participate in the initial pair of each randori segment to help things get started well.