[Ramone]

The article misses an important point: People who've done TDD know that it is the easiest/fastest way to unit-test. Few aspects of programming are more painful than trying to unit test code after the fact, especially if it was written without testing in mind.

[billmcneale]

It's not the fastest way, by far. It tends to lead to more testable code, sure, but it's not fast.

For example, TDD encourages code churn: you write tests for a lot of throwaway code.

Personally, it usually takes me two/three attempts before I'm satisfied with the version of the code that I have. Writing tests for these throwaway attempts is a waste of time.

As you become more experienced in writing tests and testable code, you realize that you no longer need TDD to write code that can be easily tested, so I see TDD more as "training wheels" for beginners.

[Retric]

I fail to see how unit tests are required for a shippable product. For a wide range of things, buggy and shipped is better than clean and ready in 3-6 months.

[steveklabnik]

But is buggy and shipped in 3-6 months or clean and ready in 3.25 to 7 months better? (that's what the time increase numbers are from TFA).

[bobbyi]

Having the flexibility to choose between those is better than having your hands tied and not being able to make the choice.

According to this article, the effect of TDD is to remove your ability to defer that decision until a time when you have more insight into which of those is better.

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

[Retric]

TDD turns a 20 month (1 2/3 year) project into a 23 to 26 month project. Which is how I got 3 - 6 months behind.

And if your product does not ship for 6 months, then your first few itterations even if faster will also be behind.

PS: (3 to 6) * (1.15 to 1.3) = (3 * 1.15 to 6 * 1.35) = (3.45 to 8.1).

Edit: No wait it's 15-35% longer so (3.45 to 8.1) months.

[brown9-2]

This seems like a false choice to me. Why are these the only two choices?