Patterns and the "TDD Conversation"
Joshua Kerievsky in Refactoring to Patterns writes about how TDD is sort of a continuous conversation with the code which enables an efficient evolution. This is quite a difference from traditional "big up front design" (BUFD) thinking, where so-called architects spend a long time planning how the system will be designed. In an internal mailing list at Microsoft I recently provided an analogy about what I think is wrong with BUFD. I received a few compliments via email so I thought I'd share it with you publicly:
It’s hard to know when a pattern is applicable on a whiteboard because you’re not getting feedback from the system. Too much design up front, especially with patterns in mind, tends to yield over complicated and irrelevant designs. TDD, with the knowledge of patterns, tends to yield a pragmatic use of patterns. The “continuous conversation” of TDD is key. Try solving a problem with your wife/husband/significant other without letting them give you feedback about what you are saying. You can talk for a little bit up front, but eventually (very soon) you need feedback. That feedback may change the course of your conversation.