DanNorth.net

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”.

The task is just detail

There is more to this than just linguistic curiosity. If you use task-oriented vocabulary it can cause you to focus on the means rather than the goal, which in turn can limit your options. My favourite example of this is the term “search engine”. Searching is the activity I have to do because I’ve misplaced my keys and I’m locked outside. What I want is a find engine!

Google realises this. When I type something into Google, it guesses what I’m likely to be trying to find, not what I happen to be typing into the box. If I type in “Stockholm map”, I’m likely to be looking for a map of Stockholm (first three results are actual maps – presented as pictures) or some information about the town itself. If I type “hotels Stockholm” I’m probably planning a trip there and voila! lots of useful results for the traveller. Other “search” engines do just that – they search, and produce lists of results. It’s then down to me to sift out the ones I care about to get me closer to my goal.

“Blur” on a problem

We talk about “focusing on a problem” in order to solve it. This is a task-oriented phrase. An alternative would be to stand far enough back that you see the problem in its proper perspective. If anything you are “blurring” on the problem – deliberately losing focus on the detail to see if any larger-scale structure emerges.

I often describe BDD as outside-in development. You start at the outside with an automated scenario, and work inwards, discovering services and collaborators as you go, until you’re done. With a legacy application it can be difficult to remain outside enough, or to get a good enough frame of reference for “done”. Blurring can help with this.

For the last six months I’ve been involved in restructuring and re-architecting a legacy code base. It’s been quite a major undertaking, and has involved a number of false starts and dead ends. (I’m planning to write it up as an experience report at some point, but given my current throughput of things I plan to write, don’t expect it any time soon.) During this project, I’ve often found myself struggling to choose between alternative strategies, or unsure of where to go next. In these situations I’ve found that stepping back and “blurring” gives me enough perspective for one of the alternatives to become “obvious”. In fact a couple of my teammates have picked up on this and will actually suggest it as an activity when we are pairing. “We’re thrashing here – let’s step back and start from the outside again.”

It could be as simple as asking “whose responsibility is this feature?” or “who is the actual client of this method call?”. You don’t need to know the answers – just verbalising the questions can give you enough “blur” to gain a better perspective.

Blur on time as well as space

Linus Torvalds recently gave a talk where he said the problem with source control isn’t branching, it’s merging. Again, by taking a broader perspective – in this case temporal rather than spatial – his insight is that the goal is a successful merge some time in the future, not the task of branching now.

As a final thought, while I was thinking about this I realised the term “behaviour-driven” contrasts with “test-driven” in a similar way. My goal as a developer is to deliver a system that behaves in a particular way. Whether or not it has tests is an interesting metric, but not the core purpose. “Test-driven” development will cause me to have lots of tests, but it won’t necessarily get me nearer the goal of delivering business value through software. So you can use goal-oriented vocabulary in your development process as well as your code to help maintain perspective on what you are trying to achieve.

Props to James Lewis for helping me formulate these ideas. And for being really good at perspective.

It turns out that having a day job can play havoc with your blogging activities. I’m posting a round-up of recent activities, in no particular order, with the intention of expanding on each of these topics in the coming weeks. But we all know what happens to intentions.

This is mostly a brain dump to make me feel guilty enough to write some of it up, so feel free to skip it if you’re busy. That FaceBook page isn’t going to update itself you know.

Simplicity

At last year’s XP Day in London I got involved in a fishbowl discussion, with the likes of Kevlin Henney among others. Kevlin gets simplicity. To me it’s the holy grail of software development, and it’s all about expressing intent clearly. If you can’t make a system any simpler, then you’re done (simple, not simplistic). Likewise if you can express the intent of an application in a clearer way, you still have work to do. Erik Doernenberg and I shaped this theme into a keynote that I’ll pretend I’m going to write up at some point.

Performance tuning

A couple of years ago I did a performance tuning gig with a major retailer in the US. It was their first foray into J2EE and they were struggling with the impedence mismatch between OO and the relational database. Over the next few weeks I’ll be writing up the various approaches we took to achieve the results we got (startup time down from 10 minutes to 45 seconds, query times down from over 30 minutes to sub-second), because in the intervening period I’ve seen some of the patterns repeating themselves elsewhere.

Agile SOA

I have my “safe” topics that I’m very familiar with presenting: coaching and learning, agile and BDD, various technology topics. Last month I presented outside of my safe zone – on “SOA for Human Beings” at the ExpertZone conference in Stockholm.

SOA is not like the other kids. On one level it’s so vague it’s almost Zen: “What is SOA?” “It’s whatever you want it to be”. Secondly, it’s largely misunderstood as being a technology thing rather than a business thing. Thirdly, it’s often deliberately misrepresented as the reason you have to purchase a particular toolset.

So I stood up in front of the 17 attendees and said: we won’t be discussing code this afternoon – we might not even discuss technology. And we all had a much better afternoon because of it. There were a number of themes that came up during that session, and I’ll try to do them justice in a future article.

Builders, Commands and Fluent Interfaces

I’ve been architecting! You know, like properly designing software on a project as a tech lead. It’s great fun – I’d forgotten how much I liked it. My favourite current toys are builders – in particular fluent interfaces – and the command pattern. Suddenly my world is a simpler and happier place. Come to think of it, I’ve just rolled off a project with Patrick Kua as my tech lead. Talks a lot of sense does Patrick.

BDD in Ruby

Got rbehave out. Phew!

BDD in Java

At some point in the last couple of months, it seems we released JBehave 1.0! It’s been a labour of love, made up of infrequent short bursts of activity interspersed with long periods of day job. Lucky for me, Liz Keogh stepped up and took the reins, and with the help of some other great developers got it to 1.0. I’m very pleased with what we’ve accomplished so far, but there’s plenty more to do. In particular I want to introduce a fluent story builder to remove the need to hand-wire all the stories, and see if we can use some Java 5 goodness to simplicate things.

Real Options

No, not the things traders buy and sell. This is an overlooked branch of mathematics that explains why deferring decisions responsibly is a Good Thing, but deferring them past their “use by” date is just dumb.

My good friend Chris Matts has written an article about real options with Olav Maassen. In a demonstration of the interconnectedness of all things, there are at least two JBehave connections here. Chris was the guy who made the observation that BDD-as-TDD was just like business analysis, which in turn led to the whole story/scenario vocabulary. Olav was the first contributor to JBehave, writing a JBehave Ant task back in 2004. They are both mad as a box of badgers which means the article makes for interesting reading.

I’ve got a number of tutorials, conference sessions and keynotes coming up over the next few months that I’m very excited about. My themes for this year are behaviour-driven development, SOA for human beings and understanding what simplicity really means. Looking at these, there is an overarching theme about getting different kinds of people talking to each other in plain English (for some value of English).

Keynote at QCon, 14-16 March, London

QCon is the London version of the excellent JAOO conference in Denmark, which has become my favourite technology event of the year (apart from phone upgrade time). They attract world-class presenters to provide sessions varying from the deep technical through to people and process topics, and they’ve done the same with QCon. What’s more, they have managed to resist the lure of the sales-pitch session, which means you get to hang out with other geeks without people trying to sell you stuff. The London event is being run in conjunction with the common-sense guys at InfoQ, and I’m lucky enough to be speaking there.

I’m delivering a keynote with Martin Fowler about the gaping crevasse between what business people ask for and what technical people think they want. I’ve presented with Martin a couple of times before – at least I know I’ll only be the second loudest person in the room.

ThoughtWorks is a “platinum sponsor”, which I think means we get to buy more drinks than the other sponsors.

BDD in Ruby at ACCU, 11-14 April, Oxford

ACCU is a conference by geeks, for geeks. With its roots in the C++ community, there are lots of strange people in weird industries like embedded systems, graphics engines and writing music software. It’s a refreshing change for me, where “enterprise systems” usually means moving data from over here to over there.

I’m actually at ACCU by accident, presenting behaviour-driven development in Ruby. They haven’t noticed yet that I haven’t touched C++ in ten years, and I’m not about to tell them.

However, the ACCU folks are developing a strong liking for dynamic languages – last year Guido van Rossum, the inventor of Python, delivered a keynote, and I co-presented a session introducing Ruby and Rails. So perhaps there’s life after the standard template library after all :)

Coaching workshop and BDD session at Expo-C, 23-25 April, Gothenberg

You know the tutorial days that tend to happen either side of a conference? Well Expo-C has adopted the model of having mostly tutorial days and hardly any conference! The 23rd and 25th are tutorial days, with two speakers presenting full-day tutorials on each day (I’m on the 23rd). The middle day is made up of seminars by a number of presenters. As the only speaker who hasn’t published a book (one of the presenters, Jim Coplien, has a small library to his name), I can safely say it’s a very solid line-up. Also, it’s one of the smaller conferences so there is lots of opportunity to hang out with the presenters.

I presented a tutorial day last year around the theme of agile delivery and thoroughly enjoyed it. This year I’m doing something a bit different, focusing on “Change, Coaching and Communication”, using NLP and life coaching principles as the basis of a one day interactive workshop. As with last year, there won’t be any PowerPoint, mostly because I’m rubbish with PowerPoint.

I’ll also be presenting a behaviour-driven development session on the seminar day.

Keynote and SOA workshop at ROOTS, 25-27 April, Bergen (Norway)

I’ve not been to ROOTS before but I’ve heard good things about it. It’s a developer-centric conference and this year it features the likes of Kevlin Henney, Jim Coplien (who I’ll be racing to Norway from Expo-C) and lovely testing guru Linda Rising.

Erik Doernenberg and I are delivering a keynote on the nature of simplicity, and we’re running a three hour workshop looking at SOA for human beings.

Keynote and SOA workshop at ExpertZone, 23-25 May, Stockholm

I met Josefin Andersson, one of the organisers of ExpertZone, earlier this year and she convinced me I had to attend the ExpertZone Developer Summit in Stockholm. Since I’m scared of Josefin, I said yes. Also Microsoft’s Beat Schwegler will be there, and he rocks.

I’ll be delivering another keynote with Erik Doernenberg, based on our current pet themes of simplicity and clarity of intent (honestly, how hard can software be?), and running the workshop on SOA for humans.

I’ve been told by the Boss that I’m not allowed out of the house in June.

Ok, so I’ve been blog-tagged. Twice in fact, by Patrick Kua and Mats Helander. Apparently the rules are that I have to tell you five things about me that you probably didn’t know, and then I have to tag a bunch of other people.

Except that this is the Interweb, blog-tagging is exponential and I’m usually the kid who gets picked last, so there are probably only about 4 people left on the planet who haven’t been tagged.

Anyway, here goes. Five things you didn’t know about me:

1. I used to do origami. A lot. For years and years I would fold little squares of coloured paper (only squares, and only coloured on one side – I’m a purist) into all sorts of birds, beasts and useless household objects. My favourite was a turtle – you had to be pretty good to fold a turtle. It took me ten years before I could fold a jackstone. I kept going back to it each year until I suddenly got it. Then I made a whole load of them to prove it wasn’t a fluke. Then I forgot again.
2. I love cycling. More accurately I love buying cycle-related toys like multi-tools, ever smaller and more powerful bike pumps, super-lightweight jackets. In fact, the sorts of things that make cycling more expensive than using public transport. When I’m feeling motivated I cycle 20km each way to work, usually 3-4 times a week. Right now I’m a lapsed cyclist – I haven’t cycled properly for a couple of months – but it’s only temporary.
3. I play drums. I was in several bands over about 12 years, and played venues like the Rock Garden in London (tiny but lots of fun) and Dorking Halls in Surrey (to about 1000 people). A few years ago I started playing hand drums – bongos and an African djembe – which have the bonus of not needing a car to move them around.
4. I got married in South Africa, on a wine farm near Cape Town. It was a fairy-tale wedding, with a horse-drawn carriage and ducks. Oh, and the bride looked amazing.
5. I studied jitsu for several years. Once I got to a certain level – fending off kitchen knives, bike chains and a katana – I found I preferred teaching to grading (in fact jitsu taught me a lot about coaching). So I never got my black belt but I’m still double hard. So don’t make me come over there.

Right, I nominate Claudio Perroni, Paul Walker, Erik Doernenburg, Arjen Poutsma and Niclas Nilsson. You’re tagged!