This is a way many people and literature talk about Behavior-Driven Development (BDD): “it encourages teams to use conversation and concrete examples to formalize a shared understanding of how the application should behave.” (wikipedia)
Focus on the application‘s behavior leads to user stories that start like this:
As a system…
Do we write code for the system?
Are we serving the system?
Is the system a stakeholder?
Continuing the story…
I want to…
Oh, so the system tells us what it wants? Are we already there?
Most software developers have a strong tendency to jump too quickly into problem-solving from a technical perspective, failing to see the problems the humans need solving.
Say we’re using state-of-the-art technology, implemented with the most amazing code, on the most advanced platforms, using valuable resources, such as time, attention, and money; it it worth it if humans’ lives aren’t any better?
Many times, the problem that needs solving is a process problem. Many times, it’s a people problem. Often times, social and/or cultural problems also get in the mix. Here’s an example of the latter:
A socio-cultural problem
In the mid 2000s, I met a group of developers in Redmond who had just come back from Sao Paulo, Brazil.
They had been working on a pilot project to improve the quality of public transportation, implementing a tracking system for the buses, so people could know with more accuracy when their next ride would show up.
The system was working great, except for this one bus that kept “disappearing” from the system for at least 30 minutes everyday. Puzzled, they developers were looking at the data, code, and everything in between.
The cause of the problem?
The bus driver found out how the system worked and figured out he could use its sim card in his own phone to make long distance calls to his family, who lived in the north part of the country. That was a time when long distance calls were still very expensive.
Most local developers would have caught that possibility that the foreign ones didn’t consider. The system was behaving according to spec. But the humans…
Maybe the problem that needs solving is dealing with some people’s natural behavior that may put them far from a bigger goal.
Maybe we’re trying to develop a solution that will acknowledge people’s natural behavior and make sure the desired outcome is achieved.
Or maybe the solution can help change people’s behavior gradually.
Here’s an example. In 2017, I started riding sport bikes (motorcycles, that is) at race tracks. It didn’t take much to realize that it can be an expensive sport. Doing my research and asking other riders how much they spend in their riding season, some would say “I don’t even wanna know!” Asking how often they ride, some would answer “whenever money permits“.
Well, I do want to know; if I know and understand where the money goes, I can identify ways to optimize my expenses and get to ride more!
Here’s one of the user stories I wrote at the time to capture that need (which I implemented in www.BeyondTheTrack.net and have been using all these years):
Estimating Costs
In order to plan out a track day calendar within my budget
As a rider
I want to indicate estimated costs for each track day
Scenarios for the story looked something like this:
Given track days I plan on attending
When I enter their estimated costs
Then I can see the budget I will need for my riding season
By facilitating a behavior of setting proper budget for goals that are important to me, my life is better. My behavior. Not the system’s behavior.
How did that work out for me in that specific case?
Comparing my Year #1 in track day riding to Year #6, the number of days I rode went up by 146%, while the money I’ve spent on it went down by 78%. Value up, cost down. Win-win in my book. The chart below shows 2017 through 2022.
The closer we get to the bits and bytes, yes, specs will tend to describe what we expect from the system. But that’s NOT where I believe we should start from.
In the great books Specification by Example and Writing Great Specifications, the authors are very specific at sticking to the definition of BDD as Dan North meant it.
In this post, I’ve put my own spin on it, as this is how I’ve practiced it over the years.
In his talk about “Leadership vs Management: What it means to make a difference”, Seth Godin talks about how people think Beethoven’s 5th Symphony should sound: the way the maestro wrote it, or the way made popular by Arturo Toscanini? Interesting watch.
Claudio Lassala's Blog 