
How to use BDD to discover value-add for your startup - prateekdayal
http://blog.interfacevision.com/index.php/2011/02/how-to-use-bdd-to-discover-value-add-for-your-startup/
======
stylejam
Very nice article. I would also like to add that writing features _definitely_
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.

I'm not saying that you _must_ use BDD, only that to me it's very useful to do
so for my own startup, that's all.

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 :)

I agree with the article about all the other points.

------
psykotic
Here I was expecting an article on using binary decision diagrams to
efficiently solve some combinatorial problem with business applications!

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.

~~~
tomjen3
While I am no fan of testing unnecessarily, that comment is really a bit too
harsh.

~~~
psykotic
Sorry, I couldn't help myself. In my defense, I was genuinely expecting an
article on BDDs and was disappointed when it wasn't!

Testing is fine. Process buzzword bingo is silly. Of the exceptional
programmers I know, not one worries about any of this.

~~~
stylejam
Where do you see process buzzwords ?

~~~
psykotic
BDD, TDD, Agile, XP, Software Craftsmanship, etc. But let's not pollute this
comment thread any further. I'll try to keep my snide asides in check.

------
alextgordon

        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?
    

Simply restating the questioned assumption does not a counter argument make.

~~~
ericHosick
You are absolutely correct. That was written too quickly and I didn't quite
think I would end up on the front of Hacker news. A friend of mine submitted
the blog article.

I'll fix it.

------
ollysb
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.

tldr, BDD can make coding a far more relaxing experience whilst helping you
focus on adding value, not waste.

~~~
ericHosick
"BDD can make coding a far more relaxing experience" is a great point. I've
written a lot of code without using BDD (before I started using BDD).

There is something very relaxing about knowing that no matter what I do to the
code I know I'm not breaking the software.

It really is a liberating experience.

~~~
nborgo
Isn't that the benefit gained from testing, rather than BDD?

~~~
ericHosick
Sure, testing does cover some of that but it is difficult to get 100% test
coverage. And the 100% coverage is the liberating aspect.

When I hear people say "We have 80% test coverage" I just shake my head. What
in the heck does that mean? It means that when I make changes to system, I can
still break the behavior. And it is expensive to get 100% test coverage. In a
startup, I agree, in many cases it might not be worth the investment.

With BDD, it is very easy to get 100% behavioral coverage. 100% coverage means
that there is no way I can break the software (the behavioral aspect). And,
using off the shelf DSLs, I can often write scenarios that require me to write
0 lines of "test code". So, I get that coverage for free (which is why it can
be very useful for Startups).

Of course, if someone lays out a web page which somehow hides the submit
button. Well... Then I guess other tools are needed...

------
jchonphoenix
I read this and was like "Why would a Binary Decision Diagram be used to
discover value-add in a startup?"

Clearly I've been in school for too long.

------
DanielBMarkham
Another take on this: <http://news.ycombinator.com/item?id=2242002>

~~~
ericHosick
First, it's great to see such a wonderfully thought out article on the selling
of programming tools to programmers. I've been doing this stuff for like 25
years now and I've seen a lot of fads and tools come and go.

I would like to try and not group TDD and BDD as similar things because in my
eye they really aren't: they both provide very different approaches to solving
a problem. If you were to simply cover TDD then I would agree with you that it
is something that focuses on programming and the programmer and operates
within that area of software engineering.

BDD, on the other hand, really has little to do with telling a programmer how
to test their code or even how to program. About the only thing BDD "requires"
a programmer to do is implement the Behavior described. There are a lot of
ways to do this, but BDD adds a lot of other cool things too (like you can
verify the requirements provided too).

So, when you mention that "The 'good' programmers all do things this certain
way" and see BDD as a tool forcing that. Well, I don't think that is the case.

The funny thing is that BDD isn't even a new thing because it relies on
scenarios. It is very similar to Use Cases with one minor, but important,
difference: there was no standardization on Use Cases (Writing Effective Use
Cases by Alistair Cockburn is a great book). Cockburn left the way scenarios
are written open to the engineers whereas BDD provides a simple language,
Gherkin, that can be used consistently across different tools (Cucumber,
Behat, Specflow are a few examples).

So, from that aspect, this isn't some new "fad" that is being sold to
developers. It is just a few changes to a well known tool: Use Case.

