Previously...
I dared to question the work of a master of his field.
I went up against Dan North.
The originator, the father, the godfather
of Behaviour Driven Development.
And not in a small way.
I questioned the canonical example of BDD.
The infamous ATM Example.
Today...
I'll eat a big fat spoonful
of humble pie.
Welcome to Development That Pays.
My name is Gary Straughan
I don’t know how much you know about my move into IT?
I used to have a proper job.
In industrial marketing.
And I left it to join a “dotCom”
My “transferrable skill” was project management.
But my dotCom Project Management career lasted less than a fortnight.
(That’s a thrilling tale for another time.)
I lasted longer - years longer - in my next role
as a Business Analyst.
A role where I wrote Functional Specifications.
A Functional Spec fits into the space between
The Business Requirements document
And the Systems Requirements document.
The three together answer the questions:
Why?
What?
And How?
I understood that at a intellectual level.
But in practice I found it all too easy to stray
from the WHAT into the HOW.
I hadn't realised how often I was doing so
until I worked with one particular chap.
He had his very own catch phrase.
I'd say something like
“The user selects an option from a dropdown"
“Implementation detail!”
“The user clicks….“
“Implementation detail!”
It was hard to get to the end of a sentence with the guy around!
He was right, of course.
There are many ways to skin a cat.
And it wasn't our job to specify any of them.
Trouble is, I quite like the implementation details.
(NOT of skinning cats, I hasten to add.)
I’m interested in user interface design.
I’m interested in usability.
Steve Krug’s book “Don’t Make Me Think” is still one of my favourites.
It’s an interest that got me into trouble
in my Function Spec writing days.
And it’s still getting me into trouble today.
Fast forward to the present day And then rewind ten months.
I borrowed a “classic” example from the godfather of BDD
- Dan North - for one of my episodes.
And for months, no one batted an eyelid.
And then they started to drip in:
comments to say that the the sequence of events
wasn’t quite right.
Among them, this email.
See what he says?
It’s an example of bad usability
That got my Steve-Krug-Don’t-Make-Me Think Spidey-sense tingling.
A usability challenge!
I love a usability challenges!
You ask for money, the card pops out You grab the card and walk away... leaving
the money behind.
Crazy!
Terrible usability!
I suited up and swung into action.
You know what happened next.
Last week’s episode happened.
You know, the one where I said this was broken.
And went on to suggest some "improvements".
I even got you in on the act, helping to refine my improvements.
And then it happened.
Mike Jones left a comment.
Mike's comments are always good.
I wondered why he'd left such a long comment.
As I scanned it,... one the word jumped out at me from several places:
ORDER
In that INSTANT, I knew I was in trouble.
Without reading on, I went straight back to Dan North's classic example
Here it is, verbatim:
Given the account is in credit And the card is valid
And the dispenser contains cash When the customer requests cash
Then ensure the account is debited And ensure cash is dispensed
And ensure the card is returned
Of course there’s a high level order here:
Context, Event, Outcomes
1, 2, 3
What about within the sections?
The Context is a description of the starting state.
The things that must be true before we get started.
They are statements of "state", rather than "events".
This is an important distinction.
Events are slippery characters.
Because an "event" changes the universe is some way,
the order of events tends to be important:
I put on my socks, I put on my shoes.
States are easier:
The sky is blue, the sun is shining.
The birds are singing.
Order isn't important.
These statements have the same property:
Given the account is in credit And the card is valid
And the dispenser contains cash
They could appear in any order.
What about the Event - or is it Events?
If we are dealing with more than one event,
then the order of those events is likely to be important.
But in this particular case,
I couldn't seem to figure it out.
Requesting cash is an EVENT.
Removing the card is also an EVENT.
But what's the right order?
It didn't help that there seemed be be different
sequences of events out there in "the real world"
My cash machine requires that I remove the card before the cash is dispensed.
But you told me that it's common for the card to be returned at the end.
And then there's the card dip,
where withdrawing the card is one of the first things that happens.
The answer was staring me in the face,
but I couldn't see it.
I went back and read Mike's post line by line.
And found this perfect sentence:
“The solution design of the user interface should be left open to
the development team to implement in whatever innovative
or minimal way possible
as long as the outcome meets desired behaviour”
This like a slap to the head across the years:
IMPLEMENTATION DETAIL!
The How, What and When of the withdrawal of the card
is an IMPLEMENTATION DETAIL!
The important event is the request for cash.
For the purposes of this scenario,
it's the only event we need to care about!
We have one more section to look at: Outcomes.
Just before we do so,
I wanted to let you know that if you’re interested in BDD,
you may be interested in this Cheat Sheet I’ve put together
- with the assistance of the Development That Pays community -
that details the differences between TDD and BDD
You’ll find a link to it on or around this video.
Click the link, follow the instructions and it’s all yours.
So yes: Outcomes
Account debited, cash dispensed, card returned
Three events, right?
I'm going to go out a limb here and suggest that they are NOT events.
When I 'borrowed' this scenario, I dropped the word "ensure"
I now think the work "ensure" is important.
ENSURE that the events have happened.
If I'm right - and I'd love to hear your thoughts on this -
this distinction means that we are not with EVENTS, but with STATES.
It's the difference between saying
I put on my socks; I put on my shoes.
and
Verify that my socks are on; Verify that my shoes are on
The first two must happen in order
The second two can happen in any order
It's the difference between events and states
Applying the same transformation to our "outcomes"
Verify that the ensure the account has been debited
Verify that the cash has been dispensed Verify that the card has been returned
Not only does this mean that the statements work in any order,
But it also 'handles' the "card dip" case.
At the end of the "transaction", we verify that the card
"has been returned".
And we find that it has.
That it was returned some time earlier...
doesn't change that fact.
That is was returned some time earlier...
is an implementation detail.
Thank you very much for watching.
If you enjoyed this episode it would be amazing if you’d
Click to like
Share it far and wide.
And hit the logo
to subscribe for a new episode every Wednesday.
I look forward to seeing you next time.
Cheers for now.