From: Avdi Grimm Date: 2008-08-19T23:28:18+09:00 Subject: Re: BDD and TDD - What are they for? On Tue, Aug 19, 2008 at 7:01 AM, paron wrote: > Yes, there's a fundamental difference between making incremental > changes and reimagining the problem domain. My background, like > Ellie's, is in greenfield situations, which colors my thinking. As she > and Avdi point out, BDD is fine for evolutionary changes, but not for > revolutions in thinking. BDD is a caterpillar tractor -- controlled > and unstoppable. Real innovation is more like dynamite. I think you missed my point. BDD is equally applicable to both status-quo development and to radical departures and prototyping. What changes is not the development practices, but the *customer* who helps determine what the proper specs should be. When you are building a typical evolutionary system, the customer is the client; the end user. When you are developing an innovative new product, the customer is *you* - or whoever has the vision for the new product. BDD/TDD is still equally important, but the person defining the specs differs. There is a line of thinking that says that TDD/BDD is inapplicable to prototypes, because the prototype will just get thrown out anyway. In my experience, though, this rarely happens - in the real world you don't have *time* to throw out the prototype, and it winds up getting pressed into service as the basis for the final product. Which then necessitates a lot of painful retrofitting of test coverage. Agile methodologies do generally accept creating "spikes" without testing up front. A spike is basically an exploratory proof-of-concept for one particular high-risk part of the application - e.g. "let's do a spike to prove that we can process 1000 SOAP messages per second". Spikes are not prototypes, however. Their scope is much smaller, usually taking only a few days to a week or two to create. As a result they are a lot easier to throw away than a working prototype. > Once you have buy-in to a fundamental change or a novel idea, THEN BDD > comes into its own. In my experience BDD/TDD comes into it's own as soon as your code exceeds somewhere around 100 lines of code. Or less. -- Avdi Home: http://avdi.org Developer Blog: http://avdi.org/devblog/ Twitter: http://twitter.com/avdi Journal: http://avdi.livejournal.com