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

21–30 of 112 posts

Re: Giving Up on TDD

#21

Post by howareroark »

aalvarado wrote: post #15
aalvarado wrote: post #13

Earlier quoted context omitted.

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 hav…

Yeah. To be honest the only unit tests I ever wrote... I wrote after I built something that I understood through and through and is likely to change very little.

I really only did it cause people tend to say... "don't use open source unless it has tests". I even did all the code coverage stuff... got it to 90%+

It was fun and amusing... certainly not a validation of TDD though.

Re: Giving Up on TDD

#22

Post by jacques_chester »

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…

> Because the benefits aren't higher, in fact they are lower

It depends on what you think the benefits are.

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

Good idea. Researchers at Microsoft and IBM conducted studies of applying TDD to real, commercial projects of varying sizes, languages, team structure and complexity.

They found that defects found in production were 40 to 90% lower. Development was slower by 15-35%, assuming that you don't count re-work after release towards the overall time spent on development.

http://research.microsoft.com/en-us/groups/ese/nagappan_tdd....

These studies were not conducted with experienced TDDers, nor with TDD advocates on staff. Some of the teams abandoned TDD afterwards.

Re: Giving Up on TDD

#23

Post by jacques_chester »

seanwilson wrote: post #17
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?

Yes: Cloud Foundry. Small teams, pair programming, TDD. I believe it is now north of a million lines, mostly Go, spread across a lot of complex, interacting subsystems. Teams are located on multiple continents, working for multiple companies.

At Pivotal we typically roll out the latest release versions of Cloud Foundry into production (PWS) in less than 48 hours after a release is cut.

Re: Giving Up on TDD

#24

Post by Anchor »

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…

> But he doesn't. Because the benefits aren't higher, in fact they are lower

I am genuinely curious, what do you mean with this claim? I mean, yes the costs are high [1], but when properly paid, do the benefits still end up smaller than without practicing TDD? Which concrete benefits we miss when doing TDD?

Uncle Bob has stated many of benefits of TDD elsewhere and did not mention them in this post. Many of his public talks on the subject are available online.

[1] https://news.ycombinator.com/item?id=11311646

Edit: link to my previous comment from yesterday elaborating on the costs

Re: Giving Up on TDD

#25

Post by jacques_chester »

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,…

Sock-puppeting is rife in Plato's books. And it is just as infuriating as Bob Martin's writing is.

But I agree with Martin more than I do with Plato. Take that as you will.

Re: Giving Up on TDD

#26

Post by simula67 »

jacques_chester wrote: post #22
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…

> Because the benefits aren't higher, in fact they are lower It depends on what you think the benefits are. > As usual my advice on this is: look at the people who build things you find highly impressive, and study how they did it. Good idea. Researchers at Microsoft and IBM conducted studies of applying TDD to real, commercial projects of varying sizes, languages, team structure and complexity. They found that defec…

Each chapter in the book 'Making Software' by Greg Wilson and Andy Oram, takes one claim usually made by software developers and examines the body of research surrounding that claim. Chapter 12 is on TDD. The conclusion was that the evidence is not conclusive.

Re: Giving Up on TDD

#27

Post by mikegioia »

exabrial wrote: post #19

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…

    The prima donnas will attack you ad hominum and call
    you slow.
I don't know whether to laugh at or applaud the irony of that statement.

Re: Giving Up on TDD

#28

Post by stuartaxelowen »

exabrial wrote: post #19

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…

    actual engineering

    prima donnas, hipsters

    have a spine
And then...

    The prima donnas will attack you ad hominum
I'm not for or against TDD, but you've gotta see the irony here.

Re: Giving Up on TDD

#29

Post by jskulski »

ryanbrunner wrote: post #6

There's definitely some good points here, but I have a huge issue with this point: > Something that is hard to test is badly designed. In my experience, TDD has a natural tendency to favour decoupling at all costs, and TDD zealots will push de-coupling units as an unqualified positive. And if your metric is "good design = easily testable and low coupling" it certainly looks that way. This mindset fails to take into c…

> This mindset fails to take into consideration the fact that tightly coupled things are often simpler to understand and reason about

You're right on a small scale. With teams or feature changes, tightly coupled things quickly breed incidental complexity.

I like what you said about decoupling not being unqualified positive. It's not, it's very good, but it's costly (with a high return). It's all about trade offs. Testing, and specifically testing-first, is expensive compared.

If I'm working on a critical piece of my system? Yep, worth it. TDD. Do I need to refactor something so I can reduce complexity with this change? TDD. Am I writing a quick workaround for better UX that will be removed after two days? TDD isn't appropriate.

It's a essential skill to have, but not the only way to practice.

Re: Giving Up on TDD

#30

Post by jacques_chester »

simula67 wrote: post #26
jacques_chester wrote: post #22

Earlier quoted context omitted.

> Because the benefits aren't higher, in fact they are lower It depends on what you think the benefits are. > As usual my advice on this is: look at the people who build things you find highly impressive, and study how they did it. Good idea. Researchers at Microsoft and IBM conducted studies of applying TDD to real, commercial projects of varying sizes, languages, team structure and complexity. They found that defec…

Each chapter in the book 'Making Software' by Greg Wilson and Andy Oram, takes one claim usually made by software developers and examines the body of research surrounding that claim. Chapter 12 is on TDD. The conclusion was that the evidence is not conclusive.

It's an excellent book.

Software engineering research has the same problem as sports science. Small samples, lots of difficult-to-control variables. No way to perform real RCTs. Not enough money or interest to really dig.

That doesn't make it useless, but it does mean exercising judgement.

Post reply on HN