(Case in point, Peter Norvig comments on a famous series of TDD blog posts that had the goal of writing a Sudoku solver, but ultimately failed:
"And I could see, right from the start, you put these two together, and you could solve this Sudoku thing. He didn’t know that so he was sort of blundering in the dark even though all his code “worked” because he had all these test cases."
http://pindancing.blogspot.com.au/2009/09/sudoku-in-coders-a...)
I mix between TDD and not writing tests until after a section of the code is done. It really depends on what I'm trying to accomplish. If I'm spiking things, I tend to just write tests to confirm my work and make sure I'm sane. Other times I know exactly what I want and write the tests first then code. Really just depends on the situation.
Good line. A lot of people will shoot back with "in the long run, it will cost you more" but the point is - a startup doesn't even know if there is a long run.
This is true if you don't have tests or your tests lack. But if you write tests as you work or a little ahead of yourself, the cost difference will probably be negligible. To each his own.
TDD isn't lean. Writting tests for things that were already proven is.
Overtesting isn't lean, but TDD is a practice which fits very well within lean (particularly, its a practice which prevents waste by doing things that aren't needed, since it concretely bounds what is necessary, as well as the more-often discussed effect of preventing additional downstream waste in the form of rework because of incorrectly implemented work that gets into production.)
> Writting tests for things that were already proven is.
I'm not sure what that sentence means; it sounds like something decidedly non-lean (if something is "already proven", writing tests for it seems to be a task known to be redundant, and thus pure waste.)
What do you mean by this?