Stephen Freeman Rotating Header Image

March, 2009:

What kind of hole have we dug ourselves into?

Update: Nice follow-up from “TestObsessed”, you can get your free certification from her. As she suggests out, I’d rather be a sucker for an elaborate joke than have this be true.


There is now, apparently, a “World Agile Qualifications Board” offering Agile certification programs (I won’t link to it directly, but it’s at waqb (dot) org). The site looks professional, but there’s not a single name or organisation on it, so there’s no pedigree—but people can apply to join the review board.

Assuming that this is more about an excess of ambition, rather than a direct scam, what does this say about the state of both our industry and the Agile movement that some mysterious person thinks that this is a good idea? Enough people have been seduced by the idea of certification, that someone is prepared to try their luck with a big-sounding title. With enough Google keywords, it might even pay off.

I’d love to be corrected, but I don’t believe this is what we’ve struggling to achieve all these years.

Java synchronisation bug on OS/X?

I’ve come across what might be a synchronisation bug while working on the book.

The end-to-end tests for our example application use the WindowLicker framework to drive the Swing user interface. Our test infrastructure starts the application up in another thread (it’s as close as we can get to running from the command line), then creates a WindowLicker driver which, eventually, creates a Java AWT Robot. It turns out (we think) that this means that we have two threads trying to load and initialise the AWT library in parallel, which hangs. Our workaround is to call a delaying method before creating the WindowLicker Driver:

private void
makeSureAwtIsLoadedBeforeStartingTheDriverOnOSXToStopDeadlock() {
  try {
    SwingUtilities.invokeAndWait(
      new Runnable() { public void run() {} });
  } catch (Exception e) {
    throw new Defect(e);
  }
}

That’s not really what invokeAndWait() is for, but it solves our problem until we can find a better answer, and we hope that the hack is at least self-explanatory.

Does anyone have a better explanation or fix? OS/X 10.5.6, Java 1.5.0_16, White MacBook 2.4 GHz Intel Core Duo. Nat‘s Linux installation works fine.

Kanban for beginners

Karl Scotland has a post on whether Kanban is only suitable for mature teams. (in case you haven’t guessed, he thinks not).

The magic of Kanban is that it all it really does is make the current situation explicit. If the team is in a position to respond then they will figure it out and do something; if they can’t then they have a much bigger problem than their methodology. Kanban does require that the people involved care about what they do (scepticism is disappointed caring) and periodically reflect, and patience (not my strongest suit).

On the whole, I’d say that Kanban-inspired improvement is most likely to stick, if the organisation can afford to wait. Sometimes the commercial situation is so dire that there’s not enough time for the team to discover its own way to more productivity.

"Basically, since about half way through last year, the global financial system has been on a work to rule"

From D-Squared

Mock Roles not Objects, live and in person.

At the recent Software Craftsmanship conference in London, Willem and Marc ran a session on Responsibility-Driven Development with Mocks for about 30 people. Nat Pryce and I were sitting at the back watching and occasionally heckling.

The first striking thing was that when Willem and Marc asked who was using “Mock Objects” most everyone put their hand up (which was nice), but then only a handful also said they were thinking about Roles and Responsibilities when they did (which was frustrating). We first wrote up these ideas in our paper “Mock Roles Not Objects” and much of the difficulty we see people have with the technique of Mock Objects comes from focussing on classes rather than relationships.

As it happens, an example popped up in the rest of the session, which was run as a Coding Dojo. What was interesting to me was how the group managed to turn around its design ideas. Here’s what I can remember about how it worked out.

The domain was some kind of game, with a hero who moves around an environment slaying dragons and so forth. The first couple of stories were to do with displaying the current room, and then moving from one room to another. It was a little difficult getting started because the limitations of the event didn’t allow enough time to really drive the design from outer-level requirements, but the group managed to get started with something like:

describe Hero do
  it "should describe its surroundings" do
    hero = Hero.new(room)

    room.stub!(:description).and_return("a room with twisty passages")

    console.should_receive(:show).with("in a room with twisty passages")
    hero.look(console)
  end
end

The expectation here says that when looking, the hero should write a text describing the room to the console. This was a place to start, but it doesn’t look right. Why is a hero attached to a room? And hero.look(console) just doesn’t read well, it’s hard to tell what it means. The tensions became clearer with the next feature, which was to have the hero move from one room to another. If we write

hero.move_to(other_room)

how can we tell that this has worked? We could ask the hero to look() again, but that means making an extra call for testing, which is not related to the intent of the test. We could ask the hero what his current room is, but that’s starting to leak into Asking rather than Telling. There may be a need for the hero to hold on to his current location, but we haven’t seen it yet.

Suddenly, it became clear that the dependencies were wrong. We already have a feature that can be told about the hero’s situation, which we can build on. If the feature were to be told about what is happening to the hero, we could use that to detect the change in room. So, our example now becomes:

describe Hero do
  it "should move to a room" do
    hero = Hero.new(console)

    room.stub!(:description).and_return("a room with twisty passages")

    console.should_receive(:show).with("in a room with twisty passages")

    hero.move_to(room)
  end
end

That’s better, but it’s not finished. The term Console sounds like an implementation, not a role. Most of the sword-wielding adventurers that I know don’t know how to work a Console, but they’re quite happy to tell of their great deeds to, say, a Narrator (as David Peterson suggested). If we adjust our example we get.

describe Hero do
  it "should move to a room" do
    hero = Hero.new(narrator)

    room.stub!(:description).and_return("a room with twisty passages")

    narrator.should_receive(:says).with("in a room with twisty passages")

    hero.move_to(room)
  end
end

The whole example now reads as if it’s in the same domain, in the language of a D&D game. It doesn’t refer to implementation details such as a Console—we might see that code when we get to the detailed implementation of a Narrator. Obviously, there’s a lot more we could do, for a start I’d like to see more structured messages between Hero and Narrator, but the session ran out of time at about this point.

Some lessons:

  1. Naming, naming, naming. It’s the most important thing. A coherent unit of code should have a coherent vocabulary, it should read well. If not, I’m probably mixing concepts which will make the code harder to understand and more brittle to change than it needs to be.
  2. When I’m about to write a test, I ask “if this were to work, who would know”. That’s the most revealing question in B/TDD. If there’s no visible effect from an event, except perhaps for changing a field in the target object, then maybe it’s worth waiting until there is a visible effect, or maybe there’s a concept missing, or maybe the structure isn’t quite right. Before writing more code, I try to make sure I understand its motivation.

Willem’s (and many other people’s) approach is slightly different. He likes to explore a bit further with the code before really sorting out the names, and he’s right that there’s a risk of Analysis-Paralysis. I do that occasionally, but my experience is that the effort of being really picky at this stage forces me to be clearer about what I’m trying to achieve, to ask those questions I really ought to have answers to, before I get in too deep.

This man is corrupting the next generation….

Cay Horstmann, Professor of CS at San Jose State University, Sun Java Champion, and consultant in Internet Programming, says

I perform an occasional unit test after I’ve encountered a failure that I don’t want to have recur, but I rarely write the tests first. If so many experienced developers don’t write unit tests, what does that say? Maybe they would be even better developers if they followed Heinz’s advice. Maybe they don’t make many mistakes that unit tests would catch because they’re already experienced. The truth is probably somewhere in between.

What that says is that we work in a horribly inefficient industry where too many developers spend their time fixing bugs (using the debugger) sent back upstream by the testers, and it looks like there’s evidence to prove it.

via Kerry Jones

Tips on Test-Driven Development

Just found this useful guide

Anyone new to [TDD] should begin with a partner who is more experienced, not only because it is safer but also because one can learn from the other’s experience.

Before starting the [TDD], it is important to have a general picture of the route and how it should be [TDD]’d. If the [TDD] is long or has a crux, you should try to pick out in advance suitable spots to rest.

Three-point contact with the [code] is an important rule in [TDD] and should be followed where possible. […] You should always have eye contact with your next [refactoring] before you start your move. Scrabbling blindly about for a [refactoring] is a waste of energy. Once started, each move should be short, decisive and smoothly executed. Long moves will tire you out quickly and beginners need to spare strength for the final section of the [TDD].

From p. 17 “Rock Climbing Basics”, Johnston and Hallden, Stackpole Books, 1995

Can I afford this business card?

I run my own company, perhaps I should make a business card like this: lego business card.

from Alexander Kjerulf via Diana of Portland