There’s a style of programming that I nicked from Jmock and now use a lot. Previously I’ve not known what to call it; but thanks to Martin Fowler I can now say Fluent Interfaces, which beats “oh you know, when a method returns ”font-style: italic;“>this and it makes it into a bit of a ”http://www.martinfowler.com/bliki/DomainSpecificLanguage.html">DSL".

That, and fashion advice too. Thank the Lord for RSS and Martin Fowler.

One of the benefits of having a chronic respiratory disorder is free flu vaccinations. A major part of the annual ritual is the interrogation by the Asthma Nurse. Now, there are two types of asthma medication: preventers are taken regularly and stop attacks; relievers are for taking during an attack. Preventers take over five days of regular usage to be effective; the reliever gives immediate and (for me) total relief.

“So why did you decide to stop taking your preventer” asked the nurse, which shows a touching belief in rationality. The reliever takes about ten seconds to bring me back to the surface when I feel like I’m trying to breathe through a snorkel while two feet underwater; the preventor takes about a week of regular usage to bed in, and stops me having to take the reliever. I just forget to take the preventer; I know I should take it, but without immediate feedback I can’t get into the habit.

The phrase “immediate feedback” in the last paragraph probably gives some idea of where I’m going here. When you are practicing test first programming, the test are driving the design: the tests are of immediate value. Interface-first tests are valuable, in the medium term…

When things aren’t going the way I’d like I’m often tempted to blame others: “it would all be okay if it wasn’t for those pesky programmers / business analysts / customers”. These responsibility holidays are comforting and relieve stress, but have the potential to ossify into a dangerous habit.

I have to remember that blaming others draws focus away from my own faults. By act or omission I am always in some way responsible for any of those failures. By focussing on what others seem to be doing wrong, I can fail to see the pressure points I might use to turn things round.

Complaining that the rest of the team do not take TDD seriously is a dead end. On the other hand, if I apply Ohno’s Five Whys……

• Why do they not take TDD seriously? Because they have not been fully exposed to the benefits.
• Why haven’t they been fully exposed to the benefits? Because they are not practicing TDD.
• Why are they not practicing TDD? Because they are not familiar with the tools and practice (and I haven’t nagged them enough)
• Why are they not familiar with the tools and practices? Because they haven’t been properly tutored in TDD.
• Why haven’t they been tutored in TDD.
• Because
  • answer 1: because I am too impatient and distracted to spend the time.
  • answer 2: because I am too engaged in trying to solve all the problems myself to get help from outside the team.

Here is the example code from my Story Testing presentation and demo for Agile Scotland. Unzip run “runme.sh” (or “runme.bat”), then point a web browser to http://localhost:5001. You’ll need Java 1.5 on your path. Any problems comment or send me an email.

It’s been a bit tricky to package for distribution because I used a toy web application using Java Servlets, JSPs, and a database. I’ve altered it so that the app hosts itself in embedded Jetty, and uses embedded HSQLDB as a database. Previously it used Tomcat and MySql.

Jetty accounts for the bulk of the 5MB download. If anyone wants a slimmed down version without the ability to run the app drop me an email or leave a comment on this post.

I’ve also posted the slides here; if you weren’t at the talk, though, I’m not sure how much sense they will make.

(In case my links are a bit cryptic, the code is here: /assets/story-test-demo.zip.)

This Hugh Macleod cartoon made me thing of Agile and large organisations…

In this post my attempted point was that if you can make a checklist for a build or release procedure chances are you can script it. The comments got a bit side-tracked, though.

I don’t have a problem with the “release management function”; my current team includes a couple of great (if overworked) release management people. My problem is with specialist teams (DBA, release, architects, business analysis, test).

Throwing stuff over the wall to specialist teams nearly always seems to take more time and effort (costs more money) than just doing it yourself; this is for a variety of reasons (differently aligned priorities, administrative / communication overhead).

Sorry Rob, I don’t think it would even help if they were to wear unitards.

Recently Anthony has decided to post more of his ideas half-baked. Rob’s decided to leave his in the oven a bit longer.

I like the gesture-response model of thought: I latch on to an idea which is interesting and tease at its flaws, which leads to another interesting (but flawed) idea.

Your Myers-Briggs doesn’t dictate your opinion of the new White Book, but I think that its interesting to consider that your inclinations may affect your view: you are not a purely rational being; you would not be able to function if you were.

Thinking about standards a bit more, most standards are a mix of de facto and de jure. I wonder if there is a good rule of thumb for getting the mixture right.