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.
