[Retric]

If something is faster, but starts later it does not necessarily win. 15% to 35% longer initial release cycles is fine for a 1 month web app, but if it’s a game that takes 2 years to release, your starting from a deep hole.

PS: I suspect, TDD ends up being something of a premature optimization on larger projects, you write tests before you know which direction you want to take the project in. Don't get me wrong Tests are great from a process improvement standpoint, but every major shift ends up breaking way to many tests that you either don’t do it, or you just wasted all that time writing tests.

[steveklabnik]

> every major shift ends up breaking way to many tests that you either don’t do it, or you just wasted all that time writing tests.

This is why I'm a BDD guy, not a TDD guy. Seems like you're writing a lot of the wrong kind of tests...

[Retric]

Thanks, BDD looks like an interesting idea, I think I will look into that some more.

Anyway, I tend to build the happy path by any means necessary, verify that's what you want, then go for TQM style process improvement to add quality. I think of it like pulling a tiny string across the river before you build a rope bridge.

It’s not hard to add heaver gage rope to work your way up to a bridge. But, good luck crossing the chasm if you don’t know how to swim or where to find a boat. While that original string may have little to do with the finished bridge, but at least you have something to fall back on when you’re trying to get the GPU to do something etc.

PS: Ok, I think I took that analogy well past the breaking point.