I’ve been quite the public speaker over the last couple of months: I gave a TDD demonstration to Software Engineering students at Glasgow Caledonian; I presented on Story Testing with FIT to Agile Scotland; last week Peter Aitken and I gave a TDD and pairing demo to the Scotland IS Agile event, using the classic “Roman Numerals Example”. I was happy with the first two – especially the FIT presentation. Last week I don’t feel things went to well.

Tom Poppendieck has a comforting aphorism – “The only true failure is the failure to learn”. So, it wasn’t a failure. Here’s what I learnt about.

• Pairing on stage. When pairing you need to establish a rapport with your partner. When presenting you need to establish a rapport with your audience; this is doubly so for a programming demonstration – just watching people code ain’t that interesting. I’m not good enough at presenting or live programming to manage both. For the time being I’m just going to “pair” with the audience.

• Vision. I think that there were three different visions on the purpose of the demonstration. The classic Roman Numerals demonstration is a sort of TDD spectacular – pulling the algorithm out of the TDD hat. I think Peter wanted a more honest (and brave) demonstration of TDD in practice; I had a rather confused idea half way between the two.

• Belief. This is probably heresy, but I don’t really believe that baby-steps and removing duplication is always the best way to drive solutions to the roman numerals type of algorithm; I can fake it; it can even be useful to fake it in order to ensure full test coverage. I feel a bit uncomfortable pretending to drive a solution that way.

In summary: next time I’ll try and engage more with the audience, have a clearer vision, and use examples I really believe in.

Update: Just pondering on what I’ve written, and I’m concerned that it looks like I’m knocking the roman numerals example, and by implication those who like to use it (eg Clarke and Craig). I don’t mean to do that. It does illustrate baby steps, “faking it”, and driving out duplication well. It can give the impression that TDD is a magic key to unlock any problem, though; unfortunately I don’t think things are that simple.

Update 2: Of course you need to simplify things in a demonstration… More thought needed…