At QCON 2008, Dan North gave a talk about BDD
. Dan start by stating that projects fail because the products come in too late, cost too much, do the wrong thing, are unstable in production and crash every day, break the rules, or the code is impossible to work with.Next Dan compares the bottom up and top down approached to delivering software. Frederick Taylor’s scientific management theory kind of says that people are lazy and stupid and as a result we need to make their work simple and we need to constantly monitor them. We need to separate work from management. Top down process on delivering software is based on premise that people downstream are increasingly pluggable and prone to make mistakes so we need to front load our process with all the smart stuff so there is less risk of something going wrong as we go further along. Since the price of defects increase the later it is discovered, we need big upfront design(BUFD). Plan, requirements specs, functional design, detailed design, test plans is hedging against the exponential cost of change, but this is in turn creates it and thus creates a reinforcing loop. There is no cause and effect, they both cause one another.
Meanwhile Deming’s premise is that people generally want to do a good job and take pride in their work and they respond well to an encouraging environment. Bottom up process builds business objects to represent business domain and then produces an architecture to wire them together.
Next Dan shares statistics that say that 60% of features are never or rarely used, 30% are sometimes used, and 10% to 15% are often or always used.
Then Dan explains that Behavior Driven Development is about implementing an application by describing it from the point of view of its stake holders. Only focus on high-value features, flatten the cost of change of anything at any stage, prioritize often, change often, adapt to feedback and continuously learn. Pull requirements as needed, evolve the design, code that can change, frequent code integration, frequent regression tests
BDD is derivative from XP (TDD, CI), Domain Driven Design, Acceptance Test Driven Planning (estimation based on building one scenario on top of another), Neurolinguistic programming (NLP), systems thinking.
BDD is getting the words right, enough is enough and more is waste while less is irresponsible, agreeing on DONE, outside-in (more systemic approach), interactions (series of interaction between people with different skills and software is an output of these interactions). People over process.
Dan next elaborates:
