Agile Pain Relief

October 23, 2008 in Software Development, TDD by Mark Levison

A few weeks ago I ran my first Coding Dojo/Randori and while the participants learned from the session there had been a few key flaws:

• The problem was too big
• The problem was in a domain that was unfamiliar to everyone
• The facilitator (me) participated too much Ouch. It was true.

This week we ran a second session and had a much better time. The key to success – pick a smaller problem and let people struggle for a good long time before making suggestions. In addition remind them frequently to ask the audience for help.

This week's problem:

Score a bowling game, (credit to Bob Martin and Ron Jeffries for the idea) based on the following rules:

• A single bowling game consists of ten frames.
• For each frame, a bowler is allowed a maximum of two rolls to knock down all ten pins
• When a Strike is thrown, the current frame is finished
• Scoring:
  • 0-9 pins knocked down: score the number of pins
  • Spare: 10 + number of pins knocked down by the next throw
  • Strike: 10 + number of pins knocked down by the next two throws.

Effectively this means the ball after a Spare is counted twice – once for the spare and once for the strike. With Strikes the next two balls are counted twice.

October 14, 2008 in Software Development, TDD by Mark Levison

During last weeks TDD Randori session I was asked, what are the advantages of TDD. Here is my short list:

• Writing tests first require you to really consider what you want from the code
• Short feedback loop
• Creates a detailed specification
• Reduced time in rework
• Less time spent in the debugger and when it is required you usually get closer to problem quickly
• Tells you whether your last change (or refactoring) has broken previously working code
• Allows the design to evolve and adapt to your changing understanding of the problem.

October 8, 2008 in Software Development, TDD by Mark Levison

We're ran out first TDD Randori session at lunch today (approx 15 attendees). I was inspired by Dave Nicolette's session at Agile 2008 and used the Danilo Santo's paper on their Brazilian Coding Dojo as a guide.

In a Randori we work as a group trying to solve a small problem using TDD:

• 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.
• 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).

I picked the problem based on a complaint I've heard from people after many of the TDD classes: "the examples are too trivial and don't speak to real world problems. I also hear that we don't enough chance to practice TDD"