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 :)
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.