In his
presentation about
Behavior Driven Development (BDD) and
Domain Driven Design (DDD),
Dan North talks about another interpretation of "BDD":
Bug Driven Development or "DDD":
Defect Driven Development.
It goes like this:
The customer comes to the developer and wants the perfect system. He describes what he wants, but its this fuzzy vision described in a business language that the developer just is not able to grasp...
The developer: "Ah ok... I understand. It is done!"
Customer: "What? What do you mean?"
Dev: "Well it is done. The system is finished!"
Customer: "Well, no ... I don't see an icon where I can start the system?"
Dev: "Oh! You are right. That's a bug! I will fix it."
... five minutes later ...
Dev: "Ok, the icon is here. Now it is done!"
Customer: "Well, no! When I double-click the icon nothing happens!"
Dev: "Oh! You are right. Thats a bug! I will fix it."
... five minutes later ...
Dev: "Ok, the the app starts when you double click. Now it is done!"
Customer: "Well, no! There is nothing in the newly opened window!"
Dev: "Oh! You are right. Thats a bug! I will fix it."
... you get the idea.
While this is a humorous story, it actually demonstrates the qualities that BDD (now Behavior Driven Development again) strives for:
Pull based instead of push based: The developer pulls new requirements from the business just in time when they are needed.
Outside-in: The development is driven by the business relevant features that are actually used and matter to the stakeholder.
Constant involvement of the customer.
Small steps with clear acceptance criterias.
Another analogy is funny:
Behavior Driven Development is an evolvement from
Test Driven Development, taking the concepts of the latter to a higher level, evolving out of a purely developer-centered discipline.
The same could be said for
Bug Driven Development: The concept of
Samurai Debugging was already a humorous technique in
Extreme Programming:
When you follow the Samurai Debugging technique, you start with a blank screen. That's not what you want, so you start debugging it, and you continue debugging it until your program does exactly what you want it to do.
Now Bug Driven Development takes this to the next level by involving the customer :-).