Here is a copy of Kent's response: "Kent Beck, Husband, father, programmer, goat farmer. The needs of a startup before product/market fit are very different t

Here is a copy of Kent's response: "Kent Beck, Husband, father, programmer, goat farmer. The needs of a startup before product/market fit are very different than those after. Before, you need the absolute lowest possible latency from idea through implementation to validation. If you can do that without any code at all, so much the better. Reducing latency gives you the chance to experiment as many times as possible for a given amount of money to increase your chances of survival. After you find a product that meets a real market need, you need to shift to a throughput-oriented engineering strategy so you can last until revenue ramps up. The practical implications of this for testing is that before product/market fit you should only write tests that reduce latency. Sometimes this means no automated tests. As a feature proves promising and you begin to elaborate it, this means just enough tests to keep the validation cycle short. If a feature is complicated AND YOU CAN'T THINK OF A CHEAP WAY TO TEST IT, you may have to write extensive tests to get the feature to a verifiable state. Then comes the transition. You've started growing. You're feeling the pain of scaling. Now you need testing. More than that, though, the whole organization needs to begin valuing throughput instead of latency. If that shift takes place, then extensive testing comes along as a natural consequence." This is a far cry from TDD. I'm glad Kent wrote it, though, because it is so true.