Very nice article.
I would also like to add that writing features <i>definitely</i> helps in providing a sound MVP.
I'm quite surprised that nobody thinks that one of the reasons a MVP fails can be the quality of such MVP, where quality != number of features.
Writing Gherkin features shows clearly what kind of application flow I'm implementing, and it happens a lot of time that I notice a step that is just unnecessary or overly complicated.
Even mockups are not as meaningful as scenarios, because they don't describe the application flow or state changes.<p>I'm not saying that you <i>must</i> use BDD, only that to me it's very useful to do so for my own startup, that's all.<p>Reading the other posts it also seems that people spends a lot of time testing unnecessary things, like a facebook login. Guys, just shoot a mock object that returns true or false, Facebook works, trust me :)<p>I agree with the article about all the other points.
Here I was expecting an article on using binary decision diagrams to efficiently solve some combinatorial problem with business applications!<p>Why this confusing initialism? Oh wait, silly me. For a second there I forgot that the intersection between people who chase such faddish mirages as behavior-driven development and people who know a bit of computer science is approximately zero.
<p><pre><code> 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: If you don’t know the problem then why are you even coding?
</code></pre>
Simply restating the questioned assumption does not a counter argument make.
I've been practising BDD for a few years now. For whatever reason I'll sometimes find myself coding without having first written a reason. You know what, I always find that I'm really not enjoying writing the code. The reason, I'm constantly having to guess about whether or not the code I'm writing is actually useful or not. Every time I write a new method signature I have to try and imagine the whole system that's involved for that feature and figure out where this little bit that I'm working on fits in. It's a lot of mental work compared to the alternative. Working outside in you never have to think about the big picture, that's where you started, all you have to do is keep drilling down into the detail until it works. There's no room for drift, if you're disciplined you can always do a minimal amount of work to get the job done. Thinking about code in this way, one little bit at a time is so relaxing. Get interrupted, that's fine, go off fix the urgent bug or whatever. When you return just your tests, see where you got to and pick up where you left off. Because you've externalised your thinking so far you don't need to carry it around in your head. You're back in flow in a couple of minutes.<p>tldr, BDD can make coding a far more relaxing experience whilst helping you focus on adding value, not waste.