Eric,  

I think that every single pro-TDD holy warrior that blogged on this tried to say that TDD is not about replacing testing.  That's the major, but common, misconception that Rocky repeated in his response.  

Doubting TDD as an effective design technique is a completely reasonable point of view.  I've found it to be very effective in creating clean, maintainable code, but the learning curve wasn't all that gentle.

I am pleasantly surprised out of all of this to see how many people like to use CRC cards.  All my career all I've ever heard is people drone on about UML when responsibility driven design is so much easier to use and more intuitive.  A lot of people happily use CRC cards in addition to TDD, which isn't much of a surprise when you find out they were both invented/described by the same person.

Eric,
I'm not sure what "holy war" you are referring to.  I wasn't aware that there was a war on.  I, too, enjoyed Rocky's post, and I love what he said about CRC-based design.  I completely agree that this is a better approach.

"Unit tests by developers are definitely not a replacement for a QA team."

Absolutely right again.

Talking of CRC cards (or SRC cards in my case (services, responsibilities, collaborations)), they've never worked for me... not least because my handwriting sucks. It also feels a bit inefficient, a bit like playing out natural selection. I had considered creating a virtual "CRC cards session" application somehow, where you'd sit at the computer and collaboratively organize them on your screen. Developers aren't very social beasts after all, and that way you can browse the web at the same time. :)

John,
There isn't one "magic" way to create software, but CRC works for me.  And I don't use index cards.  Sometimes it's on paper, a whiteboard, or maybe in my head for smaller stuff.  

About developers not being social:
That's one of my weaknesses that I try to work on.  Pair programming is one thing that forces me be be "social" and to communicate constantly.  Communication is a learned behavior, so I won't get better if I don't practice.

Jeffrey,
I'd be interested (as I'm sure would others) in hearing how exactly your CRC process works, like what the steps are you go through, what you do on paper, what you do in your head and how you work on this with your team mates. If you ever have the time to write a post on it.
John

I second John's request. I just learning TDD, DDD and now CRC (looks interesting). I am very interested in seeing how someone else gets them to play together (I'm sure you ask 10 people, you get 10 responses). Seems like both DonXML and Scott Bellware's posts on this subject has gone by the wayside.

Did you just write "I refuse to get into the holy war", in a post you titled "I'm with Rocky"? With a straight face?
Speaking up to say which side you're on.... I'd call that getting involved.

John,

There's a reason why there's multiple design methodologies out there.  I've bumped into plenty of people who simply cannot derive any possible meaning from a UML diagram.  CRC and responsibility driven design seems to be great for people that are more verbal as opposed to visual types that like graphical notations.

I happily use the RDD concepts behind CRC cards, but I can't make myself use the index cards either.