4 ms·

"Secondly, I've realised that when I don't write tests I code too fast." Excellent inadvertent criticism of TDD. Thanks for the post.

transmit101 17y ago
Can you explain more fully, please?
- angelbob 17y ago
  Presumably he's saying that if you don't write tests you can code faster. I agree with the original poster -- it's important to slow down and think about the problem. Then again, I'm a big fan of trying hard not to write code you already understand too well -- that means that you're repeating yourself :-)
  - silentbicycle 17y ago
    In some cases, couldn't the tests be the code? That's the declarative programming ideal, anyway - starting with a straightforward spec of the problem, running it, and then gradually fleshing out just the parts that need to be optimized. Sometimes, writing what I want and then writing step-by-step directions for how to do it feels like I'm repeating myself. Prolog is far from perfect (its default search mechanism gets stuck in left-recursive clauses), but it's a start, and computers have gotten considerably faster since the 70s... AFAIK, the best known success of declarative programming is writing a pattern matching specification (with ML, Prolog, Erlang, Haskell, or various Lisp macros) and compiling it to the necessary nested if / switch statements, rather than generating it by hand. I guess it overlaps with parser generators, and some other DSLs, too.
tentonova2 17y ago
I'm not religiously in favor of "tests first, always" (who actually is?), but I find that when you emphasize testing, you spend less time debugging, more time coding, and the end result is generally better engineered. After over a decade of writing software, I'm willing to accept this up-front cost in favor of long-term (and often short-term) gain. Sure, I can quickly hack out code when I'm not writing tests, but long term experience with both methodologies has demonstrated to me that it's not worth it.
- silentbicycle 17y ago
  > who actually is? Like many other 'methodologies', it has uncritical advocacy. (http://blog.objectmentor.com/articles/2009/10/07/tdd-derangement-syndrome http://blog.objectmentor.com/articles/2009/10/07/tdd-derange...) (HN discussion: http://news.ycombinator.com/item?id=866707 http://news.ycombinator.com/item?id=866707) I agree that automatic testing is nearly always a net gain, but using tests themselves as the primary driver for the design process suggests to me that the developer has little other design experience to draw upon.
stcredzero 17y ago
Actually, the full quote: Secondly, I've realised that when I don't write tests I code too fast. TDD acts as a constraint on myself, something which stops me from running ahead of myself and forces me to stick around a particular problem area for long enough to understand it better, and often learn something that otherwise I'd have missed. I don't remember ever reading a blog claiming that would be an advantage of TDD before I started. Extreme Programming was cognizant of this effect quite a while ago. (Actually all of the parts of XP were supposed to have beneficial side effects that reinforced the other parts.)

transmit101 17y ago

Can you explain more fully, please?

angelbob 17y ago
Presumably he's saying that if you don't write tests you can code faster. I agree with the original poster -- it's important to slow down and think about the problem. Then again, I'm a big fan of trying hard not to write code you already understand too well -- that means that you're repeating yourself :-)
- silentbicycle 17y ago
  In some cases, couldn't the tests be the code? That's the declarative programming ideal, anyway - starting with a straightforward spec of the problem, running it, and then gradually fleshing out just the parts that need to be optimized. Sometimes, writing what I want and then writing step-by-step directions for how to do it feels like I'm repeating myself. Prolog is far from perfect (its default search mechanism gets stuck in left-recursive clauses), but it's a start, and computers have gotten considerably faster since the 70s... AFAIK, the best known success of declarative programming is writing a pattern matching specification (with ML, Prolog, Erlang, Haskell, or various Lisp macros) and compiling it to the necessary nested if / switch statements, rather than generating it by hand. I guess it overlaps with parser generators, and some other DSLs, too.

tentonova2 17y ago

I'm not religiously in favor of "tests first, always" (who actually is?), but I find that when you emphasize testing, you spend less time debugging, more time coding, and the end result is generally better engineered. After over a decade of writing software, I'm willing to accept this up-front cost in favor of long-term (and often short-term) gain. Sure, I can quickly hack out code when I'm not writing tests, but long term experience with both methodologies has demonstrated to me that it's not worth it.

silentbicycle 17y ago
> who actually is? Like many other 'methodologies', it has uncritical advocacy. (http://blog.objectmentor.com/articles/2009/10/07/tdd-derangement-syndrome http://blog.objectmentor.com/articles/2009/10/07/tdd-derange...) (HN discussion: http://news.ycombinator.com/item?id=866707 http://news.ycombinator.com/item?id=866707) I agree that automatic testing is nearly always a net gain, but using tests themselves as the primary driver for the design process suggests to me that the developer has little other design experience to draw upon.

stcredzero 17y ago

Actually, the full quote: Secondly, I've realised that when I don't write tests I code too fast. TDD acts as a constraint on myself, something which stops me from running ahead of myself and forces me to stick around a particular problem area for long enough to understand it better, and often learn something that otherwise I'd have missed. I don't remember ever reading a blog claiming that would be an advantage of TDD before I started. Extreme Programming was cognizant of this effect quite a while ago. (Actually all of the parts of XP were supposed to have beneficial side effects that reinforced the other parts.)