Steve Freeman

Two “facts” heard on the radio today:

• there are now more mobile phones than people in the UK
• half of UK children have had no fresh fruit or vegetables in the previous week

This post has been stewing for a little while, and now I’ve been kicked into writing it up by Naresh Jain’s post on Lessons Learnt from Restaurant Business.

Since Channel 4 in the UK started supporting the Mac for their online replays, I got hooked on Gordon Ramsey’s Kitchen Nightmares series¹. I’ve never worked in a restaurant and I know that TV programmes are a manufactured narrative, but (inbetween all the swearing) there are some interesting themes that come through every week:

• cook stuff your customers actually want. Some owners get carried away with bigger ideas than they can handle;
• reduce the menu to something your staff can cope with. Bloated menus and fancy presentations cripple the kitchen staff. Cut it all back to something they can do well;
• help the staff take pride in their work. Producing stuff badly for unhappy customers is wasting people’s lives, and probably not sustainable. One of Ramsey’s triggers for cussing out the brigade is when they’re not trying—and watch their reactions when they turn it around and he praises them;
• cook your own stuff. Don’t rely on outside prepared stuff unless there’s a very good reason². Bring in good ingredients and, um, cook them;
• take responsibility. You’re the chef/owner/manager/waiter, so do your f***ing job;
• communicate. Head chefs should be talking all the time so their brigade knows what’s going on, waiters and chefs should discuss the tickets so they know what’s ordered, waiters and managers should talk so they know what’s going on with their customers; and,
• see it as it is. The building looks run down, the kitchen is filthy, the food is disgusting. Stop fooling yourselves.

I know it’s relatively easy to come in and see how to rescue a business that’s months away from failing, after all an outsider has the advantage of not having been sucked into the mess. But, even through the box of mirrors that is TV, Ramsey shows two strong drives: total focus on providing the best service to the customer, no excuses; and, total respect for the craft of cooking. He just lights up when he finds a junior with ability and enthusiasm.

Somehow, I feel this ties in with a post from another coach given to immoderate use of language, Mike Hill wrote about how raising your internal quality makes you go faster. I think there’s a commonality of purpose there that we should take note of.

1) I mean the UK version of this series. The US series is like a boil-in-a-bag version: manufactured, over-spiced, unsatisfying. In fact, the opposite of everything Ramsey is promoting. But that’s another story.

2) Yes, I know there have been some “scandals” with Ramsey’s London restaurants, but that doesn’t invalidate the point.

InfoQ has just published Udi Dahan’s talk from QCon 2008 on “Intentions and Interfaces”. It’s good to see the message about focussing on Roles rather than Classes being pitched to a new audience. That’s what we were trying to talk about in our “Mock Roles, Not Objects” paper.

I wonder, however, about his style for naming roles:

interface IMakeCustomerPreferred {
  void MakePreferred();
}
interface IAddOrdersToCustomer {
  void AddOrder(Order order);
}

It took me a little while to figure it out, but to me the issue is that these interface names bind the role to the underlying implementation, or at least to a larger role. One of the things that Nat Pryce and I discuss in our book is that interfaces need refactoring too. If two interfaces are similar, perhaps there’s a common concept there and they should be collapsed—which brings us more pluggable code. This implies that roles, as described by interfaces, should aim to be context-independent. In this case, I might rename one of the interfaces to:

interface IOrderCollector {
  void AddOrder(Order order)
}

since there will be contexts in which I really don’t care that it happens to be a Customer. That said, I think Dahan has other motivations with this naming scheme, since he also uses it to control retrieval from the ORM, but there might be other ways to achieve that.

Via Brian Marick’s other site:

“Machinery helps you pay attention to what’s important,” Wajswol says. “In cheese making, there are a couple of things you need to focus on. If you can eliminate the nonsense—the mundane, nonskilled steps, like feeding the animals or warming milk correctly—you can spend more time focusing on the texture of the curd and making sure the product comes out good.”

(my italics)

From Guy Kawasaki interviewing designer Hartmut Esslinger,

If a young person wants to be a great designer, what should he or she do?

Finally, a young person with the right talents needs to have infinite desire and never give up. I apply a simple test with young students: smash a teapot into pieces and then hand out the glue. Those who rebuild the teapot won’t make it, those who create phantasy animals and spaceships will.

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.

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.

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.

From D-Squared

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.