From: Eleanor McHugh Date: 2008-08-18T23:01:44+09:00 Subject: Re: BDD and TDD - What are they for? On 18 Aug 2008, at 12:46, paron wrote: > On Aug 16, 11:27 am, Eleanor McHugh > wrote: >> Which of course presupposes there is a clear and direct >> transformation >> between what the client believes they want, what they actually want, >> what they should actually get (which is not always the same thing) >> and >> how these can be represented in software given whatever other >> arbitrary requirements apply. > > The whole "requirements in front" idea is perfectly simple and > logical; also, typically impossible or wrong. > "If I'd asked people what they wanted, they would have asked for a > faster horse." -- attributed to Henry Ford. Very true. As my experience is primarily green-field development I've spent my career arguing with clients who not only didn't understand their problem domain but were entirely blinded to that fact by their preconceptions. This is not to say that the requirements they bring to the table are completely worthless, but they have to be viewed in terms of need much more than of wants to develop a cost-effective and lasting solution. Taking the horse analogy, a man who wants to buy six horses may be doing so because he needs to plough three fields in a day and be used to thinking in terms of three teams all running in parallel, when in actual fact a tractor may be able to do those same three fields in a single day by serialising the task and thus do away with the need for two additional teams. That's essentially the point of a faster horse. To convince the man of this you need a working tractor to demonstrate and the only test that matters is the ploughing, which is a good argument for prototyping. All other tests that you may frame for the tractor - or for the horses for that matter - fall under the general category of robustness/quality and will generally be ignored by the man at this stage unless the tractor breaks down during the demonstration. From what I've seen of BDD and TDD in practice, they focus a lot of effort into making the teams of horses as close a match to those the man wants as possible so as to achieve incredibly high satisfaction ratings: they're thus an excellent marketing technique. However what the man fundamentally needs is a more effective ploughing solution that costs him less money, and figuring that out requires a broader perspective than that provided by just-in-time requirements analysis. He probably has to put more effort into getting a tractor - as reflected by a higher capital investment and higher fuel costs - but the productivity of this solution more than pays for the extra investment. Would he be satisfied watching the whole tractor construction project from initial back-of-the-envelope design to real- world deployment? I very much doubt it. What he's interested in is ploughing, not engineering. But what he ends up with is still the better solution to his actual problem than the wonderfully supportive development of a six horse ploughing solution even though that's what he wanted all along. I can see that BDD + inspiration could develop the tractor as a solution to the problem, but could BDD on its own? How flexible is it in practice and can a project that's 100k+ SLOC of actual application (plus whatever overhead in test code) take revolutionary departures? Does it suit the traditional hacker habit of forking early and forking often? And what are the implications for all that test code? Ellie Eleanor McHugh Games With Brains http://slides.games-with-brains.net ---- raise ArgumentError unless @reality.responds_to? :reason