Duct tape context: A tale of two rewrites

http://gigamonkeys.com/blog/2009/09/28/a-tale-of-two-rewrites.html

by gthank • 17 years ago

70 13 17 years ago

fogus• 17 years ago

Wow. Call me crazy, but it seems odd that Joel's original duct tape post should generate so much chatter. Maybe I'm the crazy one?

amr• 17 years ago

You are not crazy. It is just people on both side of the debate are feeling a little extra defensive about the subject.

coliveira• 17 years ago

It is just that people don't get that methodologies are just rules of thumb. They are not laws.

There are people that will develop wonderful code using TDD, while others will do the same without it. It is a matter of skill and personal preferences.

mechanical_fish• 17 years ago

More importantly, it is also a question of your toolset and the problem at hand.

If you're a Ruby programmer, and especially if you're a web developer using Ruby, TDD may well save you time, depending on your style: There is a lot of testing infrastructure, a culture, a bunch of blog posts, a language with flexible syntax, and -- in the case of Rails -- a framework designed with the intent of supporting testing.

Whereas I can't imagine that the average C programmer has an easy time adopting TDD. Surely you don't write unit tests in C? That sounds like hell. But if not you have to learn some other language, and write your tests, and integrate them with your build system. And no matter what you do, every build takes a certain minimum amount of compile time and link time... That might be pretty fast in these enlightened days of multicore processors, but let's just say that I'm not surprised that (e.g.) Jamie Zawinski didn't invent TDD for C in the early 1990s. He'd still be waiting for his test suite to run.

TDD is a necessarily new invention. Imagine trying to explain it to the punch-card coders of the 1960s, when computer time was a precious resource that you signed up for an hour at a time in advance, perhaps days in advance. Those folks sweated blood over every line of code, trying to find and fix the bugs before it ever ran. The idea of deliberately breaking your code and then fixing it, over and over, would have been crazy.

wglb2• 17 years ago

I think the reason that has generated so much chatter is that jwz's experience goes against a lot of current advocacy--TDD, c++, design patterns. Personally, I think this is a worthwhile discussion.

And this is just from the first chapter. Spoiler: it doesn't really get any better for C++, TDD, IDEs in the rest of the book.

DannoHung• 17 years ago

Y'know, I don't like IDEs or C++ much myself, but I have never, ever regretted the time I took to write tests. I'm not a devoted TDD advocate though; sometimes I'll think of tests to write first, sometimes I'll write some code first, but I sure like having those tests there pretty soon after I'm done touching the code for the first time.

I'm gonna keep plugging away at tests until they don't make sense to me any longer no matter who tells me they're not needed.

tptacek2• 17 years ago

You know, TDD is somewhat controversial, but design-by-numbers GoF patterns aren't: you might as well be busting out UML or the Booch Method. It's a great book to learn a way of thinking about systems, but a discredited methodology (and one that was never actually intended to be a methodology).

Let's be careful about what we lump together here.

alexgartrell• 17 years ago

I actually did buy the book because of the discussion that came from it. Definitely a good series of responses.

I also bought Programming Clojure for free shipping. An Amazon Recommendation win, to say the least.

Duct tape context: A tale of two rewrites

Related Stories