[newt]

In the marginal case where you only care about one iteration, then TDD is a little bit worse. However, I am confident that without TDD, your second iteration will be slower - you'll get less done, and your bug rate will still be higher.

[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.

[joe_the_user]

What is the source of your confidence? Do you have evidence for this?

TDD advocates make assertions based on a certain common sense ("tests are scaffolding") but I don't see the present evidence supporting such assertions.

The thing is that TDD also often calls for not spending a lot of time on "Big, upfront design". I could just as easily argue that without a coherent design, your next iteration is going to be longer and that the critical thing is to master good design principles. But that belief also needs evidence behind it.

Programming is ultimately a mysterious thing and so looking at real, long term data is good, especially after you become good enough that everything seems clear to you.

[newt]

My confidence is from experience.

You could argue that without a coherent design, your next iteration is going to be longer. I'd argue the reverse - but it depends on what you mean by "big upfront design"

Every program, TDD or not, needs to get a basic architectural outline in place early on - e.g. decide if you're building a web app or a desktop client, which framework you'll use to build it. Usually you have a good idea of a lot of other major pieces of that you want in your architecture - they're there in "best practices" such as SOLID, repository pattern, CQRS, MVVM, etc. TDDs encourages "spikes" that prove the concept with a vertical slice through all layers of the app.

In my opinion and experience, "Big, upfront design" is a 1980s-1990s idea that all details of the program, not just the outlines, can be designed once before coding commences. And it is a completely false idea. TDD and agile say that you're going to redesign anyway, so you may as well accommodate that. This is where TDD speeds things up. Change is not just adding things to a program, it involves redesign on existing parts.

But I agree that an ounce of data is better than a pound of theory in this case. And number are far better than anecdote. That's what the article is for, I guess we should be reading it.