How to use BDD to discover value-add for your startup | Hacker News Reader

How to use BDD to discover value-add for your startup

blog.interfacevision.com

21 pointsprateekdayal16 comments

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.

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.

I was very happy today to see an article on Cuckoo hashing and one on space filling curves on HN. Three actually interesting technical articles that are not just fashion du jour would be a lot to ask for.

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

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.

Where do you see process buzzwords ?

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.

    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.

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.

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.

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

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

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

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

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.

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.

Reply on news.ycombinator.com