Rocky accidentally ignited the wrath of a couple .Net Test Driven Design guys (see Jeff Palermo’s post for a good example). with his recent interview on .Net Rocks, and then tries to explain his comments a bit better on his blog entry: Forests, trees, testing and design. Now, I don’t always agree with Rocky’s architecture ideas, but I definitely understand the position he is in. As someone that has also interviewed on .Net Rocks, let me tell you, it isn’t easy to intelligently express yourself just using audio as the communications mechanism, and try to be entertaining at the same time (aka not be a bore). Certain folks like Chris Sells, Don Box, Scott Hansleman, and Rory Blyth have that natural gift, but when the majority of us try it, we either come off as boring, or too controversial. There are the rare occasions that we can pull it off (with the help of Carl and the post production crew), which is what you strive for. But this a topic all onto it’s own.
But the heart of the matter is that some people get just a little to touchy about Test Driven Development(we call this stuff evangelism for a reason, because it can border on religious fervor). Rocky mentions that he is mostly of the CRC (class, responsibility and collaboration) mindset. He doesn’t buy into Test Driven Development as a design methodology (and admits that his knowledge of TDD is a bit lacking). Which is pretty amusing to me since CRC helped to spawn the Test Driven Development methodology. CRC also helped to create Domain Driven Design (which is my preferred design methodology). It seems to me that Test Driven Development and Domain Driven Design are just specialized implementations of CRC Cards. In researching this idea, when I searched on DDD and TDD, I found this cool 2 day class on Domain Driven Design by Catalysts:
Software projects have to overcome a lot of hurdles, e.g. how to get from requirements to a good design. On the first day, you learn simple techniques like CRC Cards (Class Responsibilities Collaborators) and Color Modeling. As an alternative to these analysis and design techniques, we show on an example, how you can grow design organically with test-driven development. On the second day, you learn Domain-Driven Design (as defined by Eric Evans), how you can develop the design in a language that all project participants can understand ("Ubiquitous Language").
Hopefully we can all learn to get along, since we are all talking about the same thing, teaching developers that they need to apply better engineering practices.