3 ms·
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 "irreco
by jasonkester 16y ago
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?
- ZeroGravitas 16y agoI'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.