I finally managed to catch up with Dan North last week at NDC Oslo (since we don’t seem to be able to do that in our home city).
We were talking about Declarative vs. Imperative, when Dan said something that surprised me. “There’s no such thing.”
He went on, “Every Declarative is a chunking-up of something else, and every Imperative is a chunking-down, and you can chunk up and down to different levels of abstraction.” Chunking up and chunking down are terms from NLP, and mean either becoming more abstract, or more specific respectively. Dan continued, “Even Java is a more declarative form of bytecode, and bytecode is a more declarative form of machine language.”
Of course, he’s correct. I wrote a blog post a while back on the Myth of What and How that explores this idea, too, so I shouldn’t have been that surprised.
The terms are still useful for getting us out of our feature-driven, code-oriented brain and into the mind of the business, focusing on the goals we want to achieve and the capabilities we’ll need to deliver.
However, from a BDD perspective, the most important thing is that if your scenarios are too hard to maintain, and becoming too detailed, you might want to try chunking them up a notch, and capture some conversations with people who naturally speak in terms that don’t involve the UI. And if that doesn’t help, try chunking it up some more, and talk to the people who have the goals and the visions.
Having the conversation is more important than capturing the conversation is more important than automating the conversation.
Liz Keogh, lunivore 
It’s also possible they are mixing language and concepts from different levels of abstraction. I wrote about that a while ago but it bears repeating. For what it’s worth I think Erik Meijer was the person I first heard make the explicit statement that Imperative and Declarative are relative terms.
I don’t disagree with the idea from a systems perspective. However, I want to reiterate the phrase “Systems perspective”. As you say, it is a much bigger issue than the imperative/declarative difference.
These allows us to chunk elements as systems developers and communicate those ideas to others who understand what we mean by that chunking. I agree that if we truly want to step out of our systems worlds, we have to understand the chunking elsewhere in the environment and this may involve adding elements to our perspective to make the innate concept (and hence chunk) have a richer meaning. The differences are concerns to someone, somewhere, which may not be concerns to us. Example, tonne of bricks and tonne of feathers…
…hands up those who assumed/concluded that I was going to ask about which is heavier? Now where did I ask it? Why did you fill in the gap? This ties in to what you’ve said Liz about having the conversation. To a reasonable degree people have to learn to speak the language though.
Thank you for posting this, captured exactly my thoughts on the subject and nicely done relating this to business value 🙂
being a UI developer and having direct contact with both the backend developers and designers and to some degree the buisiness decision makers, this short yet incisive post rang bells with the way each department communicates there needs to one another. in some cases this has not been clear. the final comment wrapped it up nicely…”Having the conversation is more important than capturing the conversation is more important than automating the conversation.”
Thanks!
Pingback: Different Styles for Examples in BDD – Improve & Repeat
Totally agree on this! What’s important is that the three amigos had a conversation and are in the same page. Everything else is secondary.