[_drkh]

> I too favor a "code early" strategy. Though I always write down sample data inputs and outputs on paper or in a text file. Sometimes I realize I misunderstood some aspect of an API I'm using. It's good to learn that early on.

> I'm a test-first fan, so I start coding by doing a small test of a small bit of functionality. I'm not doctrinaire, so sometimes I'll write functionality before tests, but usually not. And I write tests pretty soon after if I don't write them first.

I also do this and find it very helpful in breaking down assumptions. I will add that it has been, in my experience, best to do _everything_ to break down assumptions of any kind first - you don't want to find out far later in the process that some technical solution you had isn't viable for your needs, or even that some business-oriented solution doesn't pan out.

[retrocryptid]

That got me thinking. The reason I moved to test-first (or test-early) is I've coded myself into a corner with respect to tests, that is, I wrote code that was super-hard to test. I think that falls under "breaking down assumptions" -- I assumed I would be able to easily test code I was writing. I'm going to start using "BDA" as an acronym at work (and see if anyone thinks I mean "Battle Damage Assessment.")