Introduction

I’ve seen chatter on Hacker News about how BDD adds no value to a startup (this post here in response to this).

This blog post will:

• clear up misunderstandings of BDD
• provide reasons why your startup should use BDD
• show how BDD helps you focus on value-add

What BDD is NOT!

BDD is not only about testing or test coverage. In fact, BDD is such a mind boggling amazing improvement to software engineering that regression testing and testing are merely a measly nice to have side affect of BDD. It is not the reason why you do BDD.

BDD is not TDD. They can overlap but they are as conceptually as different as structured programming and object-oriented programming.

BDD, FDD, BVADD, ATDD – It’s all the same

Behavior Driven Development (BDD) could also be called:

• Feature Driven Development (FDD)
• Business Value Add Driven Development (BVADD)
• Acceptance Test Driven Development (ATDD)
• Story Test Driven Development

What is BDD/FDD/BVADD?

Behavior driven development drives the development of code from behavior defined through scenarios.

You don’t drive development by chatting about it (CDD), by having meetings on it, by thinking how to test your system (TDD). You simply take the behavior/features of your system and build software against that.

What are scenarios?

A scenario is a description of how your system will add value for both your business and your customer. BDD has a “standard” way of describing these scenarios known as Gherkin. By standard, I mean that once you’ve described that value add in Gherkin you can implement it in Rails, PHP, C#, Ruby, Java, etc using Cucumber, Behat and SpecFlow.

How do I find these “value add” scenarios?

BDD doesn’t find that value-add. That is up to the visionaries of the startup. However, it does allow you to add value to your company immediately by allowing you to start describing your value-add in that standard way.

The best place to start is with mocking up your system. You can use paper and pencil or a tool like Balsamiq Mockups. Once you have that, you can find the behavior (features) of your vision within the mockups.

Finding that value-add is basically done by:

• Mocking up the features
• Write about and discuss them using in Gherkin
• Chose which ones add the most value.
• Implement the feature

That fact is:

If you can’t clearly describe your value-add in a hand full of features and scenarios then you shouldn’t even begin coding.

And if you do accomplish that amazing feat you are almost half-way done with your product. No work was lost because you can now take those scenarios and implement them!

Now, and only now, should you start coding!

So BDD can help me focus on the value add of my company?

Yes! Yes! Yes!

If you spend all that time chatting about your vision to a lot of people that time is lost.

If you spend all of your time chatting about your vision to other people and mocking it out and write scenarios describing that vision then it is a great start.

If you can do all that and find that sweet spot of value that you want to deliver your customer… Well then,  you can hand that to a developer (or yourself) and know they are only developing EXACTLY what was asked for.

What this means is:

It is not possible for someone to program or spend time programming any more or less than exactly what you need to get that value-add to the market as fast as possible.

Wait! So BDD can also help describe my vision to developers?

Oh ya! I almost forgot to mention that aspect of BDD.

If you thought it was hard getting your vision understood by those who you want to invest/accept/embrace your vision then it is just that much harder to get developers to understand and stick to that vision.

Not that developers can’t grasp you vision. In fact, it is just the opposite and they might start trying to improve on it for you. That can also have it’s advantages and dis-advantages.

BDD help you get that vision across to developers and helps them stick to your vision.

Advantages are numerous

• You can’t break behavior so your system can’t break
• Easy to change engineering direction
• East to move to a new technology or implement in multiple technologies
• Can regression test code and verify requirements
• Can be used as a bridge between the Product Owner and Team
• Heavy usage of off the shelf DSLs (Domain Specific Languages) can lead to Scenarios that require ZERO lines of test code to be written (Webrat and Pickle to name a few)
• Assures that only what you ask for is being coded
• Can verify that requirements are being met. There is an actual connection between a requirement and code.

Counter Arguments for using BDD at a startup

Here are some quotes from a few of the posts on Hacker News.

• Argument: “BDD assumes you know the problem and are coding to create a solution. In startups, however, you do not know the problem.”
• Counter argument Question: If you don’t know the problem then why are you even coding?

• Argument: “Startups are all about providing value — not flexibility, not bug-free code”
• Counter argument: BDD is not only about “bug-free” code or flexibility. It is mostly about helping to provide that minimal viable product – that value.

• Argument: “So [BDD] a waste of time.”
• Counter argument: Actually, there can be no time wasted in BDD (unless you think figuring out that best value add and MVP are a waste of time). It is very possible to write ZERO lines of test code using BDD. There are off the shelf DSLs out there that have done all that for you already.