Hacker News Reader

Comment by Anchor | Hacker News Reader

> 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

View on HN

It is important to read the rest of the sentence in order for this comment to really make sense.

I am talking about any scheme of how to do things that is intended to provide benefit. These all start with "wouldn't it be better if X, because Y" and then a plan is made of how to bring this about.

Well, this plan is inevitably imperfect, so it is either that you don't get all of X, or the reasons Y were not correctly understood or accounted for.

Then, there are always some extra drawbacks that creep in that negate some of the benefits. Usually these drawbacks are very subtle, and they can be hard to notice because they are not things that the plan was trying to address.

In the end, usually the net result is negative: the scheme causes more damage than it provides in benefit. But usually it takes a long time to understand this clearly, because the drawbacks can be subtle (but sometimes they aren't, for example, in TDD, how much extra code you are writing all the time).

If I read this sentiment correctly, this means that any attempt to improve anything ("provide benefit") usually results in net negative. But I cannot imagine that this is the case. Can you elaborate?

For example, let's say I want to improve my car factory efficiency. I introduce a way to keep things running without delays on the production line. Would you say that this plan is futile too? Toyota might disagree.

Would you also say that accountants waste half of their time doing double-entry bookkeeping? Half of the transactions are extra in the same sense.

I mean, I understand your argument on the imperfection of any improvement plan, but this does not say much on the actual topic on hand. Should we discuss concrete trade-offs instead of general sentiments?

There is no contradiction.

Yes, I am saying that most plans on how to do things better are not right. Doing things better is often pretty hard.

But there always is some way to do better. The way you find that is you keep trying a lot of things until you build up an experience-based picture of what things are really like. As you get better at this, plans you formulate become more likely to be net-positive.

What I am saying is that TDD strikes me as a pretty terrible plan in the first place, the product of this kind of ideas-untempered-by-serious-experience.

Speaking for myself, I am pretty sure my own productivity would plummet were I to adopt TDD, and in fact I would completely lose the ability to build software as complex as I do; I would drop at least a level or two there. This does not necessarily speak to TDD's suitability for anyone else, which is why I am recommending to judge by output.

In general it seems that people who keep practicing TDD have been programming for more years than people who have not tried it, or have abandoned the practice. I have yet to meet a TDD practitioner who started programming that way and has not considered any alternatives. The ideas have born out of bad - serious - experiences with existing approaches.

As I said in the previous thread yesterday, TDD'ing requires months or years of practice to get really productive with, and has a fairly large set of prerequisites that one has to know in order to remain sane. It took me several years of experimenting (especially with different techniques of writing unit tests) before I found a way to be productive with TDD. I also drew the connection between testability and program architecture (decoupling etc.) fairly recently (some four years ago), and that was one of the last pieces of the puzzle that made everything work.

Yes, my productivity plummeted too, but the benefits were too good, and I slowly found the techniques needed to keep up with my old self in terms of produced features. I dread to think the pieces of code that send me deep down into debugging sessions due to non-existent test coverage.

Neal Ford (Thoughtworks) said in a recent talk that he can tell which projects were written with TDD vs. non-TDD by looking at one metric. Cyclomatic Complexity.

He said that TDD code typically results in a code base having classes with an average cyclomatic complexity of 1.5 - 2. Non-TDD code typically results in cyclomatic complexity of 15 or so.

I do think you would drop in productivity for a while, but you'd level up in a month or so because it'd force you to write more maintainable code.

> the product of this kind of ideas-untempered-by-serious-experience.

(chuckle) That's a pretty myopic view. I've written some pretty freaking complex software, and I've done TDD and non-TDD. My TDD code is waaaay better and much less brittle than my complex, not-TDD code. I hate reopening the projects where the team didn't use TDD...it's scary to change. And I forget what I was thinking when I wrote that 250 line method with all these cute little shortcuts that I thought were so cool at the time. Now I have to spend time reading the code like a man stares at ancient hieroglyphics trying to decipher the mind of an Egyptian pharaoh.

Reply on news.ycombinator.com