Comment by plinkplonk | Hacker News Reader

Comment by plinkplonk | Hacker News Reader

I'm surprised at how much attention this bit of process dogma is getting on HN.

This particular argument about the supposed efficacy of TDD depends on people accepting the equivalence of the efficiacy of TDD with the efficiacy of surgeons washing hands, just because the blog author says so.

Oh horror, how can you challenge my dogma just because I call it a 'discipline' and verbally equate it to surgeons washing hands.

Saying something is true doesn't prove it is true whether you call something a 'discipline' or not. Cults are full of such 'disciplines'. Cult members will vouch for them. A better word is 'ritual'. At best such rituals are cargo cult practices. [1]

Surgeons washing hands is a practice with empirical, unchallengeable scientific evidence supporting it,while TDD is a dogmatic practice evangelized by software process zealots, with next to no scientific evidence backing it up.

Also TDD != testing and TDD != automated testing (though the evangelizers tend to blur the differences. It is easier to argue that you should write tests, than that you should write tests before you write the code, which is a somewhat more shaky assertion. If you can paint your opponents as opposing tests (vs TDD) you have set up an easily knocked down strawman).

Programmers have written tests, including automated regression tests for decades without the blind adherence to the 'write a test first, write the code, refactor, repeat' cycle that TDD consists of.

Insisting on this as some kind of moral imperative [2] is snake oil, and it is natural that experienced devs push back against religious preaching.

The best 'poke holes in the zealotry gently but firmly' writing wrt TDD is at http://www.dalkescientific.com/writings/diary/archive/2009/1... . Bob Martin's TDD 'kata' is dealt with there in some detail. The comment thread at http://dalkescientific.blogspot.in/2009/12/problems-with-tdd... is hilarious too, with some familiar names popping up.

[1] http://en.wikipedia.org/wiki/Cargo_cult

[2] The author says as much here http://news.ycombinator.com/item?id=5331108

" [TDD] allowed us to go fast, and _keep_ going fast because the code stayed clean. I have come to view it as a moral imperative. No project team should ever lose control of their code; and any slowdown represents that loss of control."

This reaction is a bit visceral, and unnecessarily so. The "cult" and "dogma" accusations sound fairly outlandish, to be honest.

Part of the reason experienced devs push back against TDD has to do with patterns and habits. It's safe to say that TDD feels awkward to anyone with other established work patterns.

TDD is of course simply a methodology. It works well for some teams, and perhaps not for others. What it does do is impose a culture of testing and rigorousness, which is rarely a negative.

Sure, you can decouple testing from TDD, but IME teams that apply TDD have more extensive coverage than those who don't. Causation correlation caveats apply.

I personally dislike TDD because it disrupts the thought pattern I have become accustomed to using when developing software. I consider myself relatively junior, so I can only imagine how much of a workflow departure it must be for more senior engineers. However, just because it doesn't work optimally for me (or, optimally at first) doesn't invalidate the approach nor make anyone who uses it some brainwashed cult member.

I think the issue is that TDD is handy for a lot of people. They (wrongly) assume it is equally as effective for everyone else. Then, they use it as a metric to judge others. It has become the "moral imperative" Bob Martin spoke of. Which is truly awful, and elicits a strong response from many who do not find TDD that useful. Quite a bit of job postings list TDD as a requirement, in fact, which is silly. It is a bit like requiring vim or emacs.

A couple months ago, in fact, I tripped on a blog post that said (paraphrased): If you do not do TDD, then you should re-evaluate your career as a developer. This is bullshit. It angers me because I keep meeting very smart junior developers carrying around a load of guilt over TDD.

I'm not sure what it is about TDD that make people forget that these things are all tools. You put it in your bag of tricks and pull it out when it makes sense. You don't beat each other to death over what tools they use.

> Quite a bit of job postings list TDD as a requirement, in fact, which is silly. It is a bit like requiring vim or emacs.

It wouldn't surprise me if those were pair-only or pair-frequently shops, at which point it makes sense to have a common workflow & toolset across the team. Given the amount of cultural overlap TDD & pairing have (particularly in Ruby-land), this seems at least plausible.

> A couple months ago, in fact, I tripped on a blog post that said (paraphrased): If you do not do TDD, then you should re-evaluate your career as a developer. This is bullshit.

Agreed. However, there's a lot of bullshit on the internet on just about every conceivable subject. Not having read the blog in question, I wouldn't put too much stock in this post representing the opinion of the majority.

> I'm not sure what it is about TDD that make people forget that these things are all tools. You put it in your bag of tricks and pull it out when it makes sense. You don't beat each other to death over what tools they use.

Disputes over tools has nothing to do with TDD and is certainly not unique to it. I would need a spreadsheet or small database to keep track of the varied topics I've seen developers evangelize and/or get into emotional near-venomous arguments over. It didn't start with TDD, and will certainly not end with it.

The appropriate response across the board is typically empiricism, and grounding all discussions in the axiom that Data Wins Arguments.

"Quite a bit of job postings list TDD as a requirement, in fact, which is silly. It is a bit like requiring vim or emacs."

Sorry, no, TDD isn't like vim or emacs. Your choice of vim or emacs doesn't change the code you produce. TDD does. Whether you agree with TDD or not, it's completely reasonable for a job to require it, just as it's reasonable for a job to require that you know and use MVC (in their app), or Rails, or any other technical solution to a problem.

If I'm hiring somebody, they have to know TDD and apply it, or they won't work for me any more. Period. Just like they have to know what local variables are and use them. Right or wrong, it's a coding/design standard, and it's perfectly reasonable for teams to choose and enforce their coding standards.

Now, that person might be able to convince me that they have something that solves my problem (a need for easily-changed code that does what the programmer intended) better than TDD. Say, a fancy type system. If so, awesome! I'll listen. But "I'll use TDD when I feel like it" ain't gonna cut it.

>If I'm hiring somebody, they have to know TDD and apply it, or they won't work for me any more. Period. Just like they have to know what local variables are and use them. Right or wrong, it's a coding/design standard

TDD is a workflow implementation and not a coding standard per se. This is to say, code written with or without TDD may be completely interchangeable. This is not true of a coding standard.

Coding standards measurably and objectively affect the end product (i.e. "use local variables", "space/tab indentation", "no method greater than 500 lines", "follow an MVC pattern"). Can the same be said for TDD or [insert workflow implementation here]?

This may be a nitpick, but I feel it's important since it highlights why there is such disagreement on this topic.

You and thomasmeeks both said this (that code written with or without TDD may be interchangeable) and I respectfully disagree. Sure, in theory, you could write the same code, but in practice it just doesn't happen. There's a significant difference in the kinds of code that are produced.

Think of it this way. Imagine two different teams. One team has a workflow that involves carefully considering design possibilities and creating design models on paper, and only writing code after those design models have been iterated and refined for a good month.

Another team dismisses that approach as waste, and instead prides themselves on their ability to ship. They start coding on the very first day. Although they care about design, their emphasis is on shipping code, and they would never waste time on modeling.

These are workflow differences. Will the teams produce different code? Of course! They approach the work differently! That's what workflow differences mean.

TDD is a different workflow that produces different code. That difference matters.

(See also this reply elsewhere in this thread: http://news.ycombinator.com/item?id=5334366 )

Edit: I don't mean to say that TDD will lead to good code. Far from it. TDD done badly leads to some gawdawful messes. But TDD done well does lead to code that is qualitatively different than other workflows done well and that difference--the result of using TDD--is useful to me.

Well, yes, if you take it to the ship first vs what amounts to waterfall extreme, there will be profound differences in the code. I suppose if you make it your mission to analyze code to determine whether or not your programmers are using TDD, you could figure it out. But then we're getting into a pretty artificial situation.

Who cares if the code is clean and the project is successful? TDD may be a useful way to get to clean code for /some/, perhaps /most/. But this is not true of /all/. I'm not arguing against its usefulness for someone like you. That's silly, you obviously value it. I'm arguing against the "moral imperative," which is utter nonsense.

TDD is neither necessary nor sufficient for success, and we should stop pretending that it is. I create a class, it has an interface with a purpose, and I test that interface. I don't write tests first, and I don't have trouble writing tests after I write the code. I organize my thoughts on pen and paper, and use very light documentation to test the size and purpose of my methods. The projects I work on are successful, everyone's happy. This is true of several other programmers I work with on a daily basis, but not all. Several also practice TDD, and it works for them.

You're moving the goalposts. I didn't say anything (and I'm pretty sure I never have said) about TDD being a moral imperative. Nor did I say it was necessary for success, nor sufficient.

I said "It's reasonable for a job to require TDD... because the TDD workflow results in a qualitatively different code base." I chose an artificial example of how workflows change code to make the point obvious, but the real-world effect of TDD is night-and-day obvious in my experience.

I value that difference to the point where TDD skill is a core part of my hiring decisions. I'm okay with you making different choices.

Well, sure, I'm not sure I really care about what particular employers require of their employees. I think it is silly, but I doubt you care much about what I think, either. It was a minor point to me (not to you), which is why we've diverged I think. My moral imperative comment is toward the overall topic, not you.

Fair points. I think you've made a good case.

Well, no, TDD doesn't necessarily change the output of a programmer. Even if you require 100% test coverage on every commit (which isn't the point of TDD anyway), there's no way to tell if the tests were written first. It is a "design standard", sure, but so is the nearly universally maligned waterfall process.

Easily changed code that does what the programmer intended is better described as "good design". TDD is a useful design aid, but there's a lot more to good design than just TDD. If you are hitting that requirement, it is because you have good programmers, not because TDD is magic. Fancy type systems don't do much to ensure good design, either. Just like a really nice saw doesn't guarantee a beautiful cabinet.

Interestingly enough, in 2009 Keith Braithwaite concocted a metric that can pretty reliably determine whether a system has been written with TDD or not.

See: http://peripateticaxiom.blogspot.com/2006/05/complexity-and-...

That's cool, and I'm sure the author's conclusions are correct for that code base.

However, the skeptic in me can't help but point out that this is not nearly rigorous enough to say his method can pretty reliably determine TDD vs non TDD code in the general case.

I interpret Bob's post as saying that having automated tests is critical, not that TDD is the one and only way to test. I know he uses the acronym TDD but his logic all points toward the value of automated tests and he did not mention that TDD is the only way to do it.

When looked at in this light his advice is spot on for me. The kind of projects I work on would quickly get bogged down and have high failure chances without automated tests. When my current employer was in the startup phase they ignored testing, were making tones of money, hired tones of devs and wrote tons of code. At least they wrote tons of code for the first couple years then they hit a wall where it became incredibly difficult to add new functionality. Now that they have been writing automated tests for 5 years new functionality is comparatively easy to add to anything but that original project (which is still running making money but very hard to change). This is server side financial processing, user management, business logic code.

TDD is mentioned specifically several times. He starts the entire sentence about tests with:

Of course one of the disciplines I'm talking about is TDD.

We're talking about Uncle Bob here. If Uncle Bob doesn't realize there's a difference between TDD and automated tests, then there's been a whole lot of arguing about nothing for the last few years.

In other words, no, you can't interpret Uncle Bob that way, he really is talking about TDD.

I no doubt he knows very well what TDD is. Even if he is being as dogmatic as plinkplonk claims I still think his advice has merit because this and the last post are great justifications for automated testing. Attacking dogmatic TDD seems beside the point to me.

Keep in mind that surgeons had plenty of empirical evidence that hand washing saved lives; but refused to adopt the discipline for several decades claiming, among other things, that doctors did not have time to keep washing their hands.

equivalence of the efficiacy of TDD with the efficiacy of surgeons washing hands

It's a metaphor, and as such, it's imperfect. Let's give people the benefit of the doubt in their ability to understand that.

Reply on news.ycombinator.com