A bit of extra work that I took on just to keep a client relationship going has been eating into to my commute code and read time.

But now I’m back onto messing around with Rails. I have trouble with the test / code balance and rhythm. The generation of completely working code and incomplete tests throws me a lot. I’m now experimenting with trying to specify stories up front with FIT. The challenge is to try and make the most of the Rails support for tests, tied up as it is with xUnit.

Tomorrow I’m of to Switzerland; I’m attending this course on Agile Team Dynamics. Last year the two books that had the deepest impact on me were written by psychologists: David Norman’s The Design of Everyday Things and Gary Klein’s Sources of Power. This year I’m shifting focus towards cognition and psychology (Update: whatever that is).

Fitnesse provides a convenient method of editing, running, and organising tests. It’s good for teaching and demonstrations, but I wouldn’t choose to use it again on a production project: it does not play well with source control and I am not satisfied with the facilities for altering functionality (ie tests) within a team environment.

The problem with naked FIT is that it works best with HTML. Direct editing is too much trouble; the WYSIWIG editors I’ve tried can be awkward to use: for instance, Mozilla composer requires too many mouse actions when inserting FIT Library-style single row tables; it also tends to insert br elements within cells, confusing FIT parsing. Microsoft Word html editing is a one way street and feels very wrong.

I’ve been experimenting with using Markdown for FIT tests: Markdown is a perl script to turn structured text into HTML, based on text email conventions. Unlike Wiki syntax, the text version of the document is readable and well formatted. It does not support tables so I’m pre-processing my FIT files before piping them through Markdown. Here’s part of an example test in markdown (plus my table support):

Expenses
========

I want to record expenses, to help calculate how much money 
the company owes me, and so that I have a record for the tax man.

An expense is a <em>virtual</em> outgoing as opposed to an actual payment.  For
example if I buy a book costing 10 pounds using my own money then that is 
recorded as an expense; the subsequent payment of 10 pounds to myself is 
recorded separately (see "payments" story).

Validation rules
----------------

|valid and invalid expenses|
|date         |description                         |amount|valid? |reason                       |
|13-Jul-2005  |Agile Web Development with Rails    |125.50| yes   |                             |
|11-June-2005 |Agile Web Development with Rails    |      | no    | amount is required          |
|13-Jul-2005  |Agile Web Development with Rails    |  0.00| no    | amount may not be zero      |
|13-Jul-2005  |Agile Web Development with Rails    | -1.00| no    | amount may not be negative  |
|13-Jul-2005  |Agile Web Development with Rails    |fish  | no    | amount must be a number     |
|13-Jul-2005  |                                    |125.50| no    | description is required     |
|             |Agile Web Development with Rails    |125.50| no    | a date is required          |
|xxxx         |Agile Web Development with Rails    |125.50| no    | date should be a date       |
|29-Feb-2005  |Agile Web Development with Rails    |125.50| no    | date should be a valid date |

Update:Rob Lally has pointed me to Bluecloth, the Ruby implementation of Markdown. That makes life a bit easier, but at least I learnt how to pipe into a perl script from Ruby.

From Andy Swan, for Object Oriented and Encapsulation.

Generic

adj.

1. Of or relating to a product or component which is so configurable that it is harder to use than to write a solution from scratch.
2. A product or component able to fulfil every requirement except for the most crucial 5%.

“The business require a generic solution for this”. “Couldn’t we make this more generic?”. See: useless, architectural astronautics, enterprise.

Enterprise

adj

1. Provides equally mediocre performance and is equally difficult to implement at all scales.

noun

1. Mythical organisation in which enterprise solutions are appropriate.

“…, but is it suitable for the enterprise?” “Beam me up, Scotty.”
See: generic, architects, Enterprise Java Beans

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…

Talking of the Scotland IS Agile event, the other presentations were very good. Rob Lally said something that is particulary worth repeating. He was talking about being landed with a hot potato project last year. Inheriting a two year project with about 8 weeks to an umoveable deadline and facing a complete rewrite from scratch, the first thing things they did was to make sure all the important things were in place (source control, continuous integration, a good set of estimated stories):

“We follow these practices because we believe they give us benefit. If you have a practice that you drop when you’re under pressure, then it is a dead weight. It’s not worth following when you’re not under pressure.”

(I paraphrase from memory.)