Jason Gorman“TDD is best used when the requirements are clear.”
And I counter that TDD is best used to clarify the requirements.
Chicken, meet egg.
I'm still baffled by people who claim they can write executable code given a set of vague (or no) requirements, but not executable tests.
Jeff GriggI'm with *agile*, in that we really only need sufficient "requirements" to do the work that we're about to do. And most of that can be "informal" communication.
(OK; a bit more, for overall project planning and direction, but not much.)
And I go a lot further than that. I hate the word "requirements." I say that it's misleading fiction. We have lots of "want to haves," but very few strict *Requirements*.
…
And I recently noticed that I differ significantly from (at least) common pre-agile assumptions/"knowledge," in that, …
For prototypes, demos, exploratory work, etc., I find that …
*Fewer and less detailed requirements is BETTER!!!*
Like, "Give me some breathing room, man!"
For a quick, throw-away demo or prototype, I want a rough outline, with goals we want to accomplish. *NOT* a detailed field-by-field and attribute-by-attribute Formal Specification, with QA Test Cases, etc
(on Requirements for a prototype or demo, ...)
pre-agile people say
"But you might not have *ALL* the requirements!!!"
I say, "Nonsense!"
"The purpose of this demo is to show that we can add a couple of fields to these vendor-built tables and screens, and enter customer-specific data. The question of precisely what each label text is, exactly how wide each field is (visually), etc, etc, etc, etc, … is mostly time-wasting nonsense."
It's Throw Away code!