I also can not believe how hard it is to convince people of the advantages of testing.
I often see stories that are not accepted multiple times simply because the product owner has changed the intent of the original story. Tests really help to define what it is that the product owner wants before a line of code is even written.
In the bigger picture, how much "more time" does it really take?
Dumb story, but my dad taught me how to do word working: making European Cabinets. So many times he would say "Measure twice, cut once." This, in some convoluted way, could apply to software engineering.
There's a reason they say that though. Unless you happen to have a board stretcher in the truck, cutting something too short ranges from "expensive" to "irrecoverably fails the entire project."
Compare that to writing code. Fixing something you did wrong is so trivial that I'll often find myself writing 3 variants of a bit of code and testing rather than pulling out a sheet of paper and doing a bit of math to make sure I code it correctly.
"Should this be cos(theta) or -cos(theta)?"... code, compile, check, whoops, delete, compile, check, done.
That's waaay better than "134 inches, I think", cut, fit, whoops, phone Jerry: Hey, could you pick me up a new piece of #4 crown moulding on the way in?
I'm intrigued to know whether your "code, compile, check" anecdote was meant to argue for or against TDD as it could go either way.
I guess the point you're responding to meant that "eyeballing" whether something actually works is the equivalent of "estimating" a length, a couple of easy tests is the equivalent of "measuring once" and "measuring twice" is taking the extra effort to build a small suite of tests with corner cases, a small sign of having learned from bitter experience.
Of course with automated tests you are literally measuring twice (indeed, measuring many times) even as the tools and materials change out from under you.
I also can not believe how hard it is to convince people of the advantages of testing.
It's about as hard as convincing people of the advantages of static typing. Not to pick on Ruby particularly, but those guys go crazy for writing their own tests for things a compiler could tell them "for free".
Software is free, so if you make a wrong cut, it doesn't matter.
Untrue; tell that to the person who's paying the QA teams who have to validate your code. Or the patch teams that work 48 hours straight to get a hotfix out because something broke after deployment.
I often see stories that are not accepted multiple times simply because the product owner has changed the intent of the original story. Tests really help to define what it is that the product owner wants before a line of code is even written.
In the bigger picture, how much "more time" does it really take?
Dumb story, but my dad taught me how to do word working: making European Cabinets. So many times he would say "Measure twice, cut once." This, in some convoluted way, could apply to software engineering.