Perhaps when you just release something once for once customer and never look at the code again. If you actually want to maintain something and release it multi

Perhaps when you just release something once for once customer and never look at the code again. If you actually want to maintain something and release it multiple times this is very untrue. Let us say that a feature takes twice as long to implement the TDD way. So without tests it takes N and with tests it takes 2N. Sounds like a clear win for omitting the tests, right? No, very wrong.... How do you even know any of your previous features still work? Testing? Hmm.... not automatically if I get the gist of what you are saying... Manually? O dear.... Hmm.... You do realize that it is very easy for code to have unintented consequences, right? So, ideally, with every release any feature could be broken. You have to test them all N.... manually... If there are m releases this would be m N. If m is some percentage of N. E.g, on average you release every 10 features, we see that development time suddenly becomes of the order of N^2. Ow.... the TDD development time is still order N..... Could it perhaps be that this statement is actually incredibly short sighted.... Then there is the code quality issue. The stuff that was written 20 years ago was somewhat hard to refactor because noone dared because who knows what would break. So basically every code base would degrade into a mess and become harder and harder to maintain over time. A code base that is maintained with automated tests can be improved as time goes on with relatively low risk.