A trend I’ve noticed in the software development community is that there are a large number of developers who resist the new wave. Many of those who spent their formative development years doing procedural development went kicking and screaming into the OO age; some suggested that it was an inappropriate tool for many problems. Many C++ developers looked at Java as a toy, not useful for any real work. And I’ve met enough Java developers who thought that Java was the last word in programming languages.
Certainly we should question newfangled tools and techniques, and insist on putting them through their paces. OO is not the best tool for every problem, Java did suck big time when it first came out, and yet there are now some significant advantages to continue doing business with it. Challenges ultimately help the tools & techniques improve.
Experimentation and innovation is at the heart of the software industry, not active resistance. But it’s far easier to sit in a corner and make as many possible excuses for not doing something. I know, because I’ve done so myself. There are plenty of jobs out there using old technologies, and places where people are happy with the status quo.
So, TDD. Some of us strongly believe in it, only because we’ve seen benefits firsthand–not just from toy Stack examples, but from working on systems that range from tens of thousands, to hundreds of thousands, and millions of lines of code. Ahh, but the stack example is all the people sitting in the corner see, because that’s all they want to believe is behind TDD.
I agree with the vocal dissenters that TDD should not always be used, but not for the lame list of excuses they often come up with. Primarily, the reason is that the typical American software team just isn’t that good. TDD is a reasonably tough discipline to get a handle on, and most developers are still struggling with OO, language, and tool basics.
What’s interesting is that TDD would ultimately help these people the most–some of its best potential is its use as a learning tool. The vocal dissenters, on the other hand, are usually reasonably sharp developers who already have a good notion of design. Thus they can’t quite understand why a technique that promotes more decoupled and cohesive designs is important–“duh, we already get it.” Particularly, for example, if they don’t happen to work with lots of typically underachieving coders.
Is TDD overhyped? Not a chance. There are still mountains worth of learning that TDD will promote in the minds of the majority of the developers out there. For those who don’t want to do TDD, don’t do it.
Can TDD be dangerous, and lead to disasters? Yes. This is true for any tool in the wrong hands. That also includes insisting on emphasizing test-after–I’ve seen that lead to plenty of failures and wasted time. TDD, like OO or any other tool/technique, is not for everyone or every project. But in the right hands, I’ve seen TDD work wonders on software projects.
Comments
George Dinwiddie March 17, 2008 at 11:01am
I agree … that TDD should not always be used.
Jeff, this statement puzzles me. While I agree that it’s quite possible to create high-quality software without TDD, and equally possible to create crap while using TDD, I can’t really think of a situation where I think TDD should not be used.
Maybe I’m just misunderstanding your point.
Hi George, thanks for the comment. In the sentence starting “Primarily,” I’m alluding to the fact that if you don’t have the discipline or desire to do TDD right, then it can cost you more than not doing it period. This is based on a number of experiences working with teams who viewed TDD as someone else’s (usually a VP’s) checklist item. The tests they produced were terrible, unmaintainable; ultimately they fell into disuse as programmers made excuses as to why they couldn’t worry about them.
I agree, there aren’t any (applicable) technical applications for which I feel TDD should not be used. (Applicable meaning OO and other languages for which xUnit support exists.) TDD does have its weaknesses around driving in threading, and deriving (not implementing) algorithms, but that’s usually (and should be) a tiny fragment of most apps.
George Dinwiddie March 17, 2008 at 12:14pm
Jeff, that makes sense. Just going through the motions of anything is a waste of effort.
Jay Packlick April 3, at 2008 02:01pm
I’m just musing here but sometimes I wonder whether this is a skill that CAN be learned by everyone Jeff.
Some people seem wholly incapable of mastering the abstractions necessary to develop decent OO code. Perhaps some people have a similar problem integrating TDD into their habits? Ironically, for those who struggle with mastering OO abstractions, TDD would seem to provide a basis for improving their code; it promotes SRP since it’s darned hard to test a new 500 line method.
It would be interesting to list all the arguments against TDD and engage in some honest inquirey into the mental models behind the objections. It’s important to remember that there is no such thing as a ‘best’ practice; there are only better practices within a given context.
Hi Jay–Thanks for the comment!
There are some postings out there (and other resources) where you can find people posting objections, but I think many of them are dishonest. Beust, for example, posted a long list of reasons why TDD was bad on JavaRanch a few months ago, and he spends time in his recent book railing against it. Most of the reasons came across as a smart someone who just wants excuses to keep doing things his way.
There are also the two articles in Better Software, in which I find some of the debate reasonable, and other claims simply ridiculous or ignorant.
I agree that TDD is probably a skill that some people aren’t capable of learning, like OO. But I think most sharp developers can learn it–if they really want to. I tend to fall on the harsher side of “this stuff (OO or TDD) isn’t really that hard,” and maybe people for whom it *is* too difficult should find a better-suited position.
Jay Packlick April 3, 2008 at 03:53pm
Ultimately it gets down to the question, “Are we writing software that’s easy to change?”
Changing code safely without tests is hard. Writing tests after the fact is usually a pain. As the old saying goes, anybody can write software that a computer can understand. Until the value of intrinsic quality is more widely embraced, we’re going to see a perpetuation of very bad code written by people better suited to other contributions to society.
Jay Packlick April 3, 2008 at 04:01pm
I think it’s important to make this point again though; any discussion of whether a practice is better or not is meaningless without a context. ‘Better for WHOM’? is an important question to ask. For example – for somebody who can instantly construct a galaxy of classes and their relationships in their head without benefit of tests – it’s going to seem a waste of time.. particularly if they work in a development shop of one. To the poor suffering soul who has to maintain or change code spun by such geniuses, the answer may be quite different.
Great point, and one that I’ve alluded to before. Beu*t says that others shouldn’t bother with TDD for its design benefits, because *he* is already good enough with respect to creating clean designs. Maybe he is one of the rare few, but the problem is that he imagines that everyone else is capable of thinking at that same level.
Maybe working in a fantasy land like Google quickly takes you out of teach with reality.
