Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Giving Up on TDD

blog.cleancoder.com

Post reply on HN
Print view View original

11–20 of 112 posts

Re: Giving Up on TDD

#11

Post by howareroark »

jblow wrote: post #5

For many paragraphs, I thought this was a parody of TDD defense, but then it turns out it wasn't. His 'defense' of the point is basically: Look, when you do TDD you have to put a lot more work into the tests than you thought! It is not just a simple thing! Okay, fine, but ... Before embarking on TDD, the programmer had a picture in his head of what the costs+benefits of this change would be. Now you are telling him t…

I like your usual advice! I imagine there are a lot of very ingenious things hidden within the code of people who have never written an article. Or even just contradictions to articles that they may have written.

I find a lot of articles tend to just build upon common assumptions with a unique twist. Makes sense though, people want to read things that validate their assumptions. People want to write things that people want to read.

Re: Giving Up on TDD

#12

Post by LordDragonfang »

legulere wrote: post #2

> but he said he was just using it for some home projects I think here lies the biggest problem. For small/hackish projects you barely get any benefits from test driven development but still have the higher costs. Test-driven development means that you will spend more effort while developing, but will have to spend less on maintaining in the long run. The fun part about home projects is that you don't really have to…

I spent the majority of the article thinking it stood for the "top-down design" that my intro to programming professor was so fond of.

Re: Giving Up on TDD

#13

Post by aalvarado »

jblow wrote: post #5

For many paragraphs, I thought this was a parody of TDD defense, but then it turns out it wasn't. His 'defense' of the point is basically: Look, when you do TDD you have to put a lot more work into the tests than you thought! It is not just a simple thing! Okay, fine, but ... Before embarking on TDD, the programmer had a picture in his head of what the costs+benefits of this change would be. Now you are telling him t…

TDD is better than no tests most of the time I think. So at least that's a gain altogether.

Re: Giving Up on TDD

#14

Post by ktRolster »

dave2000 wrote: post #9
ktRolster wrote: post #7

Earlier quoted context omitted.

Q: Why should that be different than any other type of rhetoric? A: If you want truth, read a scientific study, not a blog.

Q. Are there actually proper studies done by and of proper developers writing proper (ie not trivial crap) code which demonstrate the pros and cons of TDD?

A. This one is probably good, it compares actual software teams: http://www.infoq.com/news/2009/03/TDD-Improves-Quality It shows in increase in quality, but with an increase in development time.

It is my un-studied assessment that the improvements seen from TDD are primarily a result of the programmers thinking more. It pushes you to think of every edge case.

It also gives more experienced programmers a chance to mentor younger programmers (for example, you can easily look at the test coverage and say, "look, you need to test these things too." It's harder to do that (though still possible) without tests).

Re: Giving Up on TDD

#15

Post by aalvarado »

aalvarado wrote: post #13
jblow wrote: post #5

For many paragraphs, I thought this was a parody of TDD defense, but then it turns out it wasn't. His 'defense' of the point is basically: Look, when you do TDD you have to put a lot more work into the tests than you thought! It is not just a simple thing! Okay, fine, but ... Before embarking on TDD, the programmer had a picture in his head of what the costs+benefits of this change would be. Now you are telling him t…

TDD is better than no tests most of the time I think. So at least that's a gain altogether.

I do TDD rarely, I like it when I'm on pristine projects, I feel it works when working alone on code you're outside your paying job. Or a library that you don't need to do much exploration programming.

I add tests after the fact for most of my programming, usually because that's how I feel more comfortable. Sometimes it is a net win to figure out how something works by experimenting with different ideas and start having a feel of the software you're creating. Without slowing down for trying to think about correctness every time you write something down.

TDD should not be, "An always on" kind of thing, I feel like most of what software has taught me is "Use where better suited" which this I think is the main reason why I feel I differ with his view which I think it is, use always. I kind of think that people with those bracelets about "always doing TDD" are thinking.

Re: Giving Up on TDD

#16

Post by me_again »

greenyoda wrote: post #8
me_again wrote: post #4

Q: Are you sick of the Socratic method? A: Oh God yes. Q: What's wrong with it? A: It's overly verbose, condescending, and allows you to give the appearance of resolving a debate when all you've actually done is talk down to a sock puppet.

"It's overly verbose, condescending, and allows you to give the appearance of resolving a debate when all you've actually done is talk down to a sock puppet." I agree with your criticism of the article's style. But to be fair, if you're arguing with yourself (as the author is), it's not really the Socratic Method, which is a dialog with another person. If you don't get to control what questions the other person asks,…

Agreed- if there are 2 real people debating, it's much more bearable. Ironically some of the canonical Socratic dialogs (http://www.gutenberg.org/files/1643/1643-h/1643-h.htm) have the same problem - Meno's slave is too obviously Plato's mouthpiece IMHO.

Re: Giving Up on TDD

#17

Post by seanwilson »

jblow wrote: post #5

For many paragraphs, I thought this was a parody of TDD defense, but then it turns out it wasn't. His 'defense' of the point is basically: Look, when you do TDD you have to put a lot more work into the tests than you thought! It is not just a simple thing! Okay, fine, but ... Before embarking on TDD, the programmer had a picture in his head of what the costs+benefits of this change would be. Now you are telling him t…

> As usual my advice on this is: look at the people who build things you find highly impressive, and study how they did it.

Are there any big popular open source projects that follow TDD?

Re: Giving Up on TDD

#18

Post by c0achmcguirk »

jblow wrote: post #5

For many paragraphs, I thought this was a parody of TDD defense, but then it turns out it wasn't. His 'defense' of the point is basically: Look, when you do TDD you have to put a lot more work into the tests than you thought! It is not just a simple thing! Okay, fine, but ... Before embarking on TDD, the programmer had a picture in his head of what the costs+benefits of this change would be. Now you are telling him t…

> As usual my advice on this is: look at the people who build things you find highly impressive, and study how they did it. This is much more fruitful than reading the output of people who want to spend all day telling you how to program (which leaves very little time for them to build software that is impressive, i.e. they never even test their own ideas!)

"Uncle Bob" Martin has built a lot of impressive things. Most notably FitNesse [1] the service level test framework. He tests his ideas out and is a great teacher.

I've been doing TDD for years thanks to Uncle Bob, Martin Fowler, and Roy Osherove (who have all built impressive things) and I've leveled up as a result. In fact my entire team has leveled up with this simple discipline.

I've yet to meet an anti-TDD zealot who has actually spent a month developing the art of TDD. The detractors tend to be people who write really brittle tests that are a pain to maintain.

[1] - http://FitNesse.org

Re: Giving Up on TDD

#19

Post by exabrial »

Tdd is actual engineering: requirements first, set expectations, plan, estimate, build. Silicon Valley (generalization) has extreme shortsghtedness when it comes to building software, there are a lot of prima donnas, hipsters using whatever is cool,tech decisions made on opinion rather than measurement, and NIH.

Have a spine and push for tdd. The prima donnas will attack you ad hominum and call you slow. But it feels pretty damned good to be right.

Re: Giving Up on TDD

#20

Post by EdSharkey »

legulere wrote: post #2

> but he said he was just using it for some home projects I think here lies the biggest problem. For small/hackish projects you barely get any benefits from test driven development but still have the higher costs. Test-driven development means that you will spend more effort while developing, but will have to spend less on maintaining in the long run. The fun part about home projects is that you don't really have to…

My home projects become tragic when they get past the trival size and I haven't been TDD'ing and designing all the way through.

I think part of my problem is that I cannot devote a consistent level of effort every week to my current home project. Sometimes I'll leave and when I come back to it, I'm lost without a test suite and wind up rewriting huge swaths of it.

Really good tests also serve as up-to-date documentation of your design. If you code in Java or Groovy, check out the Spock Framework. Spock tests read like a story. I wish there was a Spock-like DSL for JavaScript development.

Post reply on HN