Bug Driven Development: Samurai Debugging Reinvented

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.

from Extreme Programming Refactored

Now Bug Driven Development takes this to the next level by involving the customer :-).

follow me on twitter, I need some friends :-)