Jelle Druyts .NET Consultant
Just another ignorant weirdo from Antwerp, Belgium trying to make sense out of it all
There's been a lot of fuss lately around the Guidelines for Test-Driven Development (TDD) that's just been published on MSDN.
I don't want to join the mud-slinging fest since I don't feel I can adequately represent the Agile community here, but this seemed like a good time to mention how I see TDD:
Test-Driven Development is like going to the grocery store with a shopping list.
Hear me out.
If you need to go grocery shopping, you can take what I'll conveniently call the "bachelor approach", which means going to the store, traversing all the aisles, throwing everything in your cart that looks remotely delicious, and not knowing in advance how much you'll wind up spending. As you mature (which is an optional step), you'll notice that you're spending way too much money on stuff you don't actually need or can't use. So in time (or until you meet someone with more experience), you'll probably start thinking in advance about what you actually need, making a list before going to the store and then buying only what's on that list. That way, you'll have a much better idea in advance what you'll be spending and as you do this more and more, you won't get caught with groceries you don't need or have to throw away.
As I see it, this is just what TDD offers: by defining the specifications for your software (the shopping list) before implementing them (actually shopping and buying), and then writing only the minimal amount of code that's necessary to meet these requirements (only buying what you have on your list), your budget will be more predictable and you lower the risk of feature creap by not going wild on features you don't need.
That said, the "bachelor approach" can of course be more fun, and yield some pleasant surprises. But in serious enterprise software development, this is often a luxury that you can't afford.
Update: Sam Gentile has just posted a more accurate definition of TDD (mine isn't 100% waterproof but I think it helps transmit the message), and Microsoft's Rob Caron has announced they'll be fixing the original article that caused the upstir. Now if Microsoft would only pull all the pages off of MSDN that show how incredibly "cool" and "productive" it is to go straight from your GUI to the database, while failing to mention that there are reasons why you would want additional layers in between. The definition of n-tier should really include the precondition "where n > 2".