Goal-oriented vocabulary – saying what you mean

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

13 comments

  1. A good read, indeed. It is quite noticeable that many people with a technical background have a hard time formulating the goals without already putting in thoughts about how those goals can be reached from a technological perspective. At that point in time it already restricts the number of possible solutions to a problem.
    I have been following your blog for some time and in fact thinking about behaviour-driven development has helped me personally to improve figuring out how and what I should test in a system. The pure TDD approach always had me thinking about how to apply testing, because I wasn’t specifically focusing on the goals. Focusing on those really can help to be productive and deliver better quality :)

  2. Christian · ·

    In the book “Writing Effective Use Cases”, Alistair Cockburn describes a similar concept for adjusting the right “goal level” of a scenario described in a use case.

    When a scenario becomes too detailed (blurred), the goal level can be raised by asking “WHY” the actor performs certain steps.
    The goal level (going into details) can be lowered by asking “HOW” the user performs certain steps.

    The same concept for lowering or increasing the goal level applies to the examples you gave:
    WHY do you want to remove the cap? – to open the bottle.
    HOW do you want to open the bottle? – by removing the cap.
    To raise the goal level further: WHY do you want to open the bottle? – because I want to drink a beer. (and so on …)

    I am frequently using the WHY/HOW questions for adjusting to the right detail level in requirement analysis. Interesting to read that a similar concept is useful in development as well.

    1. I really like that technique. NLP uses a similar thing called “chunking”. You chunk up to get a broader perspective and chunk down to get finer-grained. You can even “chunking sideways”, which involves using metaphors or lateral thinking to gain a deeper insight.

  3. > Hence “bottle opener” rather than “cap remover”.

    Dan, what did the bilingual sign say in Swedish? I am guessing “Kapsylöppnare”, which is the commonly used Swedish word for “bottle opener”. Directly translated to English, it means “cap opener”. How’s that for goal/task-oriented. :D

    1. Excellent! I like how some Swedish words translate in a utilitarian way. I noticed that “menu” translates as “price list” (as opposed to “food list” :)

  4. What is BDD? – Part 2…

    What is BDD? – Part 2…

  5. Interestingly, kids seem to ask “why?” most of the time – hardly ever “how?”. Does that show that kids are rather goal-oriented?

  6. I find it interesting that I actually find it much more difficult to use goal directed programming languages like Prolog, Icon, or Unicon. This is usually because I can’t figure out why the program did what it did, when it wasn’t what I expected. This probably says more about me than anything else, but some 35 years after SHRDLU and its block world we still can’t generally get a cogent explanation out of such systems.

  7. [...] Olhando por aí, uma justificativa interessante que eu achei foi a seguinte, no blog do Dan North: [...]

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

    I understand this style of development/design, especially if you focus on collaborations/interactions. Having said that I’m not sure that the resulting specifications are good examples of usage, or at least I’m not sure they will then act as good acceptance criteria.

    So what I’m really wondering is how you make BDD work practice?

    I’m certainly coming to my own understanding of BDD but I’m finding it hard to get a good understanding of the best way to do use it.

  9. Dan, I really appreciate all the work you’re doing to advance the integration of analysis and design. I think it’s fantastic, but I’m worried that, although the lexicon of BDD is meant to clarify, it obscures something. In particular, it seems to me that BDD scenarios are meant to replace what we commonly call story tests, and I think that’s a great idea. At the analysis level in particular, calling these things examples or scenarios, rather than tests, keeps everyone involved in analysis(1) focused on two important goals: understanding what we’re building, and knowing when we can stop building it. I am concerned, though, that your readership is starting to think BDD scenarios are meant to replace Programmer Tests, the kind that help programmers drive low-level design. I hope they’re wrong.

    When we come down to low-level design, it’s not enough to drive the desired behavior and hope that results in enough tests to cover the space. If we’re practising evolutionary design, then we need tests as a pool of change detectors to aid in refactoring. I find this statement not to be enough: “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.” My goal is to be able to deliver such a system regularly and indefinitely, which implies not only having the right behavior, but also having low cost of maintenance, and the less easily I can refactor, the more the marginal cost of a feature rises. I write tests to ward off project heat death, and I’m concerned that if we abandon tests entirely, we will lose that intention.

    So it seems to me that the choice of BDD or Story Test-Driven Development is largely one of taste and style. As you write, teaching the concepts without the word “test” have their definite benefit; however, I imagine that if we tell programmers to specify behaviors and not write tests, we’ll lose something valuable indeed. It may be that we need to teach them BDD first, but I don’t think we should breed the desire for testing out of them.
    —-
    (1) I prefer everyone on the team be involved in analysis, but I recognize how rare that is.

  10. [...] Olhando por aí, uma justificativa interessante que eu achei foi a seguinte, no blog do Dan North: [...]

  11. “I am concerned, though, that your readership is starting to think BDD scenarios are meant to replace Programmer Tests, the kind that help programmers drive low-level design. I hope they’re wrong.”

    I agree, there is definitely a growing group of people who do use BDD at the lower levels and don’t seem to believe in the scenario/story driven approach.

Follow

Get every new post delivered to your Inbox.

Join 484 other followers

%d bloggers like this: