[bhousel]

I think that TDD works great only when you have a clear idea of what you're building.

I think that TDD is probably not appropriate for a team that is still trying to figure out what they should be building. Software needs to be incredibly malleable at this stage, and the developers can expect to be constantly refactoring and throwing away big chunks of code. Most early-stage startups find themselves in this situation, this is why you are getting so much pushback here.

But yes, once you have a solid vision of what software should be, TDD will help the software stay true to that vision.

[unclebobmartin]

I agree that in a startup software needs to be incredibly malleable, and the developers can expect to be constantly refactoring and throwing away big chunks of code. That's precisely what TDD helps you do. You _can not_ refactor without a suite of tests to protect you; all you can do is hack.

If you need your code to be malleable, for God's sake make sure you have a suite of tests you trust with your life. Otherwise you'll be slowed down by the fear that you'll break the code.

[mattvanhorn]

Actually, TDD is the way you figure out what you are building. People who start with a solution in mind may write tests first, doing a kind of pseudo-tdd, but they are not reaping the benefits of letting the requirements drive the design.

This is NOT TDD:

1 - Think of a solution

2 - Imagine a bunch of classes and functions that you just know you’ll need to implement (1)

3 - Write some tests that assert the existence of (2)

4 - Run all tests and fail

5 - Implement a bunch of stuff

6 - Run all tests and fail

7 - Debug

8 - Run the tests and succeed

9 - Write a TODO saying to go back and refactor some stuff later.

see: http://cumulative-hypotheses.org/2011/08/30/tdd-as-if-you-me...

[bhousel]

I don't think we necessarily disagree. In the blog post, it looks like the author was training people on "true" TDD by using pair programming and a simple game like tic-tac-toe or rock-paper-scissors as the "target". This worked because teams were using TDD to evolve their design into something that they already knew pretty well.