I've posted a new article today entitled TDD Design Starter Kit: It’s All about Assigning Responsibilities. 

One of the most difficult things in TDD is just writing the first unit test, especially when the user story is complex.  It's also difficult to deal with external resources like databases in unit testing.  Personally, I still like to sketch out a skeleton design on paper or whiteboard before I jump into the unit testing.  More and more I've found myself using design techniques from Responsibility Driven Design as a quick way to break down a coding task into constituent parts just to find a place to get started.  I don't really use Class-Responsibility-Collaborator (CRC) cards in any formal way, but just the activity of creating a list of the responsibilities within the coding task is a good way to start a story.  I still prefer crude UML sketches for visualization, but I generally list responsibilities instead of methods in the class diagrams.  Call it the "Jeremy Modeling Language."

It's always good to have more tools in your Intellectual Toolbox than just TDD.  I obviously think TDD is very important, but sometimes it's just not enough by itself to create good designs.  I've worked with some developers that I would term "XP Zealots" with a capital "Z."  They've read everything they can find in the Agile/XP canon, but are disdainful or ignorant of anything prior to or outside of the Agile world.  That's a terrible mistake and a quick way to stunt your growth as a software developer and coder.  The more tools at your disposal, the more likely that you'll be able to solve complex coding and design problems.

TDD means writing the unit tests before the code as a way to define the expected functionality of the class, but it's perfectly acceptable to think through the design somewhat before you write the unit tests.  There's a point of diminishing returns for this kind of upfront thinking, but I think that point is different for different people.  I think I do much better when I do some preliminary sketching.  I can't just sit in front of an IDE and start writing unit tests.  I've worked with other people who actually can.  I've also worked with some developers who absolutely cannot derive or process any information from any non-code artifact.  These folks really struggle with any kind of complexity because they don't have any tools to break apart the complexity.

Responsibility Driven Design and CRC cards are the work of Rebecca Wirfs-Brock with some contributions from a couple of guys you've probably heard of named Kent Beck and Ward Cunningham.  Like so many other things in software development like Agile development, Design Patterns and Refactoring; RDD was largely formulated by the Smalltalk community.  I don't think very many people use Smalltalk anymore (but its logical heir, Ruby, seems to be exploding in popularity), but the impact and influence that Smalltalkers have had on software development is unmistakeable.

I have a silly personal theory that the different competing philosophies of software development are a product of their proponents past coding experiences.  The Agile crowd that favors continuous design are from Smalltalk, a very malleable language to program with.  The Model Driven Architecture, design upfront because coding rework is evil crowd is made up of people with C++ experience, not the kind of language you want to go around and do evolutionary design with.  Go ahead and make fun of my little pet theory.