I very much agree that knowing when to test and when testing is not needed is an art, not a science. I also hope that your readers know the difference between writing tests and writing code using tdd.
My biggest problem with your statements comes down to the idea that you claim tdd can be bad (particularly, it would seem, for startups) and yet you do not give an alternative which has equal or greater benefits without the perceived overhead cost. You say we should constantly questions whether certain practices are worth it in stead of blindly following red/green lights. Fair. But how will questioning practices give you the knowledge that your code is not broken when a junior developer makes a change "somewhere"? How will questioning practices allow you to better refactor when you pivot quickly?
I have worked in many startups and I know time is money and bank roll is king. But I believe that tdd allows you to keep those financial concerns in the black longer. If not tdd, what is an alternative method? "not writing code in tdd", is certainly an alternative one, but is it a good one?
To be clear: I did not say TDD was bad. I simply said it might not always be best. I took that a step further and suggested that with a start-up, and especially an early stage one, is probably not worth it. Not that it's bad or wrong. Simply that the costs might outweigh the benefits.
If you aren't market tested and/or market validated, I would suggest that getting something out the door is probably more important than test coverage. Because odds are those tests you wrote will be worthless when you pivot. There's a cost to writing tests, and the benefit from those tests are increased when they are reused. If you use a test once, then pivot and have to scrap it, you would have been better off hacking your way through the first release and getting to that first pivot faster.
Once you start to gain market traction and you actually know what the market wants you to be then your world changes and your approach to writing code should as well.
And as for junior devs, that's a tough one and a reason I avoid hiring junior talent. Not avoidable for all managers, but I didn't write my post to be the new bible. Quite the opposite: I think we're a bit too worried about making sure we're doing what everyone else says we should be doing. Rails is omasake and all...
I'm just tired of hearing everyone talk about TDD as if it were a given. Protecting against SQL-injection? That's a given. Being a TDD-based web startup? Not so much.
The problem with articles like this is that people who don't work in web startups and aren't writing tests at all will see this and go "writing tests is hard, that guy on HN said testing wasn't worth it, therefore I'll carry on without writing tests". You seem to live in an environment where people are already advanced in their software practices, but I doubt this is representative of out industry as a whole. Your analogy with SQL-injection is quite revealing. I can assure you that protecting against SQL-injection is not a given for everyone.
The irony is that if testing is over-hyped, it's not where it would be much needed. Too many big-budget long term developments don't use testing at all. Because there are no tests people are scared to make changes because it might break something, so they never refactor and the code becomes a big mess which obviously makes it even more scary to change.
I felt like a hungry man reading an article about how food is over-hyped :)
Sometimes writing tests takes an inordinate amount of time compared to the amount of value they provide. I worked on one project in which we were spending 70% of the time writing tests. The scope of the project was small, and the uptime requirements were light, so we ended up just throwing out all tests. It never crashed in production and we were able to iterate on new features much more quickly,
My biggest problem with your statements comes down to the idea that you claim tdd can be bad (particularly, it would seem, for startups) and yet you do not give an alternative which has equal or greater benefits without the perceived overhead cost. You say we should constantly questions whether certain practices are worth it in stead of blindly following red/green lights. Fair. But how will questioning practices give you the knowledge that your code is not broken when a junior developer makes a change "somewhere"? How will questioning practices allow you to better refactor when you pivot quickly?
I have worked in many startups and I know time is money and bank roll is king. But I believe that tdd allows you to keep those financial concerns in the black longer. If not tdd, what is an alternative method? "not writing code in tdd", is certainly an alternative one, but is it a good one?