Remember what it felt like the first time you rode a bicycle completely on your own? After a lot of practicing and falling down you did it. Finally the freedom! From that moment on it only went better and better. After a while it even becomes a second nature and you cannot even imagine how it is not being able to do it.

This experience is exactly what I had while learning Behaviour Driven Development (BDD). After years of experience in web development and having tried so many different ways of working it dawned on me that BDD is different.

The beginnings

The first time I saw a feature file it wasn’t love at first sight. Yet another agile “DD” thing and most likely it will ad additional steps in the workflow. Not that I minded that if it helps the project, but soon it became clear that I misunderstood BDD. The most common mistake people make is that they think it is about testing and is a big brother of TDD.

This is something that I have always loved about my profession. Getting requirements from stakeholders and moulding them in usable software. The problem with how I worked (and a lot of people still do) is two things namely tests and documentation. A lot of developer really love coding new stuff or completely refactor the old. Being focussed on solving a complex problem with a nice design pattern for example does give a kick.

Business value

Having said that is safe to say that no customer/manager/stakeholder cares about your fancy strategy pattern nor the awesome new framework you used. From the outside in it isn’t even visible most of the time. They care about the desired functionality and if it brings the business value as they hope it will.

In the interactions between the various people that Dan is talking about it is very important that they understand each other. This is exactly where my love for BDD began to grow. “Give me an example of what you just said” and then the examples brought so much more insights then i expected. Who would of guessed that a simple question like that could be a complete game changer and finally really understand the problems the domain expert is dealing that.

Now we can actually focus on what brings value together. However talking about sinon.js and websockets should be done with your tech buddies 😉

Awareness

Since doing more and more BDD in my projects and as a second nature asking more questions it is becoming clear to me that non-technical people are completely unaware of solutions for their basic problems. They find their way around it. I find myself asking: “Are you really copy pasting that every day for an hour?”. It really makes me aware of what should be build.

On the flip side when explaining the feature files and running the executable specifications that came out of it often brings awareness to the stakeholder that their requests have a bigger impact on development than they thought.

Conclusion

Riding a bicycle is something you will always know how to do once your learned it. The same goes for learning BDD and I encourage you to take the path of learning it. It is hard to fully grasp I must admit, but very much worth it.