Overcoming Impediments to Test-Driven Development

Recently, I had the chance to sit down with Scott Bain, author of Emergent Design and an expert in Test-Driven Development. He wanted to talk about what he has seen as impediments to implementing Test-Driven Development: impediments that arise before an organization decides to adopt TDD and impediments that arise after adopting TDD. He bases this on his conversations with clients who are in the midst of implementing TDD, on his coaching experience, and on own personal journey with TDD has he has incorporated the concepts into Net Objectives training in Design Patterns, TDD, and Analysis.

I recently completed the process of getting a book published ("Emergent Design"). It was my first time doing this, and I thought it might be valuable to some of you if I shared some of the things I learned about writing a book, and about the publishing world.

Emergent Design (audio of the webinar)

What is design? An opportunity to mitigate risk. A way to look for eliminating waste. It is certainly not simply the "thinking" part of software development.

What is design? When do you do it? How much to you do? And how do you begin?  

As teachers of Design Patterns and TDD, David Bernstein and I are often asking these questions. Invariably, we include the notion that one engages in "design" (not necessarily up front design, mind you) as a way to mitigate risk, among other things.

But which risks? Can you mitigate all risks? Do you even know all the risks that you might need to address in design? In most cases, the answer is almost certainly "No."