Great communication skill is essential in making an optimal technical decision.
Behaviour-Driven Development (BDD) is a tool that can help teams communicate better.
Let me tell you a short fiction about how BDD helped a team succeed:
In the beginning, there was a team who were building a product that will make millions of pounds.
Let's call that team Granola, because who doesn't like good old granola?
They struggle to deliver as the product should submit data to the legacy system at the backend.
Given the legacy integration challenges, a new architect was hired to help Granola tackle those complexities.
They were sitting in their ivory tower, observing and collecting information. It's a big enterprise after all.
One day, the architect decided to soar and strike up a conversation with Granola's PM to solve the integration challenges.
Architect: So, would you like the system to be synchronous or asynchronous?
PM: What do you mean by that?
Architect: Is the form sync or async?
PM: š§š
<Long discussion>
PM: Let's reconvene in a week.
Another week passed, and it was time to soar.
Architect: Give me your decision. Is it async or sync?
PM: I, uh, I'm not sure if that's a product decision, to be honest.
Architect: But I need to know if it's going to be async or sync to architect this product.
PM: š¤š
These types of conversations went on for weeks. Poor Granola. By now, they are blocked and unable to move ahead.
Is it going to be sync or async? It's all a mystery.
In all the frustration, the famous Cucumber Newsletter landed in the architect's inbox.
The newsletter introduced BDD. It talked about how it has saved some communication costs in Gherkin Ltd. It showed how communication can be easier when a Given/When/Then language is used.
That looks extremely simple, the architect thought.
Let's give it a go, it's time to soar again.
Architect: *Given* that the form has been filled out. *When* the button is clicked. *Then* what do you expect to happen?
PM: I expect the data to be readable in the legacy system.
Architect: And *Then* what happens to the form?
PM: I would expect it to show that it's been successful.
Architect: Do you expect it to show the submitted data in the table below immediately?
PM: Oh yes, of course.
There are sparks in their eyes now.
The PM thought, finally, this person is talking in human language.
The architect thought, finally, the PM is making a decision.
Architect: *Given* that the form has invalid data, though. *When* the button is clicked, what *Then*?
PM: It immediately shows an error.
Architect: That's expensive. How about we *Then* send an email instead? Here are all the options I can think of ...
<Productive conversation>
A month has passed. Team Granola is now collaborating really well with the architect and delivering at a steady pace.
Every time something is not clear, they would sit together and talk in the Given/When/Then language, even writing it down for a shared understanding.
Even better, the developers are now taking what's been written down as an inspiration for their tests.
And they lived happily ever after.
The moral of the story:
ā
BDD is a communication tool that's useful in a certain context.
ā BDD is a silver bullet, adopt it, and all your problems will disappear.
I hope this gave you more insights into your original questions @twtyagi
twitter.com/twtyagi/status/1578425720136556548