"insecurity driven development" is probably a good alternate title for TDD, but instead of taking it at it's trollish face value it can generate a good analogy.

"insecurity driven development" is probably a good alternate title for TDD, but instead of taking it at it's trollish face value it can generate a good analogy. If you start walking down a dark alley - you start feeling insecure. You've got a few options from that point. You can back out of the alley and hey, no more insecurity. A little embarrassing but you're feeling OK, you just have to go the long way round the block. You can push on through the alley in the dark - something bad could happen or you could get through fine. You don't really know until you've popped out the other side. Or you could carry a god-damned torch. Obviously when carrying a torch, you don't have it turned on all the time, just when you wander into darker areas where you're less sure of the environment. It lets you walk at full pace without stubbing your toe or getting mugged or whatever. In more concrete terms: I'm a bit of a poor-weather TDDer (same with pair programming) If i start working on something that could be algorithmically challenging, cuts across multiple layers of our app, touches something scary (like our accounting code, because i don't want to lose any of our $$$), or am just plain stumped - I write a test. It fails. I make it pass. I write the next. I make it pass. I realise my code looks like ass, I refactor. The tests still pass. I can give an actual example from this week. Our app is a large RoR app that serves multiple sites from the one codebase based on an internal DSL we have. We're in the final week of a must launch redesign (date was set because of a bunch of marketing, etc) and I get an urgent and large last minute change dropped on my desk (i'm sure you all know that feeling). I'll admit my first move wasn't to go TDD, I just went for the quick and hopeful move of quickly adding some code that looks like it should work to our DSL. It didn't. So my very next move, knowing that I have a deadline I must hit with a risky technical change, was to start writing tests. If i hadn't, I'd have to be verifying my code works by checking around 3 different pages after a server restart which is both slow and 4 layers away from the changes. So it was faster in real time. I'm not a big fan of TDD zealots, TDD is just another tool in the box. But TDD haters really get my goat. You're willfully shutting yourself out of a tool that can make your life easier, and help deliver code faster.