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.
"Ah, but Jason, how can I write tests if I don't know what the code's supposed to do?" isn't the slam dunk you think it is
Mark IJbema@jasongorman when it's very unclear I like to experiment more though. I typically do write a test, but very high level and typically with a debug statement at the end so I can play around a bit. When I have clearer what I want I throw away (or comment out) my code and rebuild with TDD.
Sometimes this leads to the same code, but more often than not I end up with a better interface
@mark When it's unclear, I talk to my customer 🙂
@jasongorman I've mostly worked in product companies where we can often have a bit more freedom on which way to interpret functional demands. So given a vague description I can search out an implementation which "fits well" in our existing software and verify with business.
Steve Fenton ➜@mark @jasongorman I do this, too... but usually regret doing it without TDD. I'm building the discipline to throw away the prototype and rebuild it based on what I learned, but test-first so I end up better designed.
@jasongorman @mark @kentbeck it's one of those "simple but hard" things... when you have something that works, there's a lot to overcome to throw it out! I'm challenging myself to do this on something I wrote recently. This post might give me the leverage over my own fear to get on and do it 🚮
@stevefenton @jasongorman @kentbeck when I was in college I learned that most of the work was in the thinking/discovering/learning and only very little in the code itself.
Mind you, this was no official lesson. In one of my first courses I had to write an XSLT and I didn't know XSLT and it was hard and it was done over the course of two months.
Then my editor asked: "the file has changed on disk, do you want to reload". I thought, sure why not. 1/2
@stevefenton @jasongorman @kentbeck but as it turned out, I was over my quota, so my last save had left the file empty.
I was going to be evaluated in an hour, and I actually was able to reproduce the XSLT in an hour.
This was a surprisingly useful lesson! 2/2
Kent Beck@stevefenton @jasongorman @mark Ward taught me this one. We had some code that worked but we weren’t happy at the end of the day. He reached over and shut off the machine. I was shocked. The next day we recreated it all better in half an hour.
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!