Blog

Business people want estimates. They want to know how much it’s going to cost them to get a solution, and they want to know how likely it is to come in on time and on budget. And of course quality is not negotiable.

There’s a one day domain-driven design event happening at SkillsMatter this Friday, 19 June in London. I’m not speaking this time so I get to sit back and enjoy some talented folks talking about really applying DDD rather than just theoretical stuff.

Next week I’m doing a new talk at the Better Software Conference in Las Vegas about learning models, where I was planning to talk about various learning styles and about how ineffective and systemically flawed most school systems are. Then I read up on Edward de Bono’s Six Thinking Hats model (I’ve linked to Liz Keogh’s write up because it was her who introduced me to it), which I’ve subsequently used to facilitate a workshop, and was amazed to say the least. So much so that it caused me to turn the Learning to Learn talk on its head.

A friend of mine has a Far Side desk calendar that he describes as a barometer for how busy he is. Some days he finds himself tearing off a whole bunch of pages because he’s been too busy or distracted to tear one off each day.

It’s finally happening - I’m writing a book! Well ok, the remarkable David Chelimsky is writing a book. It’s called Behaviour Driven Development with RSpec, Cucumber and Friends and myself and a few other folks are contributing in varying degrees.

…or why Mockito is my new friend.

Some ancient history ¶

Back in 2003 I started work on a framework called JBehave. It was an experiment to see what JUnit might have looked like if it had been designed from the ground up for TDD rather than as a unit testing framework. I was also starting to use the phrase “behaviour-driven development” to describe what I meant. The jbehave.org domain was registered and the first lines of code written on Christmas Eve 2003, much to my wife’s bemusement. Over time JBehave grew a much more interesting aspect in the form of a framework for defining and running scenarios, or automated acceptance tests.

Should examples/tests/specs/whatever be DRY (Don’t Repeat Yourself)? I’ve been thinking (and talking and arguing) about the value of test names recently and whether they are just unnecessary duplication, but that’s the subject of a future discussion. This is about the actual content of your examples. So, should your examples be DRY?

A discussion unfolded recently on an internal mailing list that tied together two of my favourite topics, namely learning theory and Lean.

Right now I have a whole pile of blog articles backed up that I’m in the middle of writing. This post jumped the queue because it is by far the most important.

If you are reading this with Internet Explorer 6 you are at risk ¶

Ok, first things first. If you read this blog using IE6, you should check your machine for malware using Microsoft’s anti-malware tool or your favourite anti-virus suite. You should also consider installing Firefox with its ad-blocking goodness and lack-of-ActiveX-ness.

Next week I’ll be talking about Best Practices, a current favourite topic, at the ExpertZone Developer Summit in Stockholm. Last year I ran a half-day workshop about SOA and gave a keynote with Erik Dörnenburg about simplicity in software, and this year I wanted to do something a little different. So when I heard there was a track called called “People Matters Too” I was keen to get involved.

Last October I was privileged to give a keynote talk at the Øredev conference in Malmö, Sweden. It was a late substitution. The original speaker, testing guru James Bach, had to cancel at the last minute for personal reasons. I felt pretty intimidated stepping into his shoes, especially since the other keynote presenters were Joel Spolsky and Andy Hunt, but I figured since no-one had heard of me I’d probably slip under the radar.

I’ve been pretty slack at letting people know about upcoming talks. I could blame workload or burnout or any number of other plausible-sounding reasons, but a lot of it is just down to not prioritising very well. I should fix that.

I was in a hotel in Stockholm recently and I noticed a bottle opener attached to the wall in the bathroom. There was a bilingual sign under it which got me thinking about the term “bottle opener” itself. (I was giving a talk about BDD the next day so I was already thinking about how language is used.)

It occurred to me that “bottle opener” is a great example of goal-oriented vocabulary. The device itself is actually a cap remover, and it only works on one particular design of metal cap. The reason I use it, however, is to enable me to get to the beer in the bottle. Hence “bottle opener” rather than “cap remover”.