Agile and Test-Driven: A Marriage Made In Hell?

Agile and Test-Driven go together like a horse and carriage... or do they?

Thanks to an excellent series of articles at Raganwald, I'm currently rethinking some of my old prejudices against agile and test-driven practices, to see if i'll start adopting them as a more central part of my style. (Note: I'm not against either of these practices, but i'm certainly not a true believer)

Thus i've been trying to uncover my hidden objections, to see if they can be overcome. But along the way a few boggling conundrums have presented themselves. See what you think.

Problem Number One.

One of the premises of test-driven development is that bugs cost hundreds of times more to fix if caught later. That's cool right?

One of the promises of agile is that when you follow its practices you flatten out the cost of making changes late in the game. That's also pretty cool.

But doesn't this mean that the use of one practice lowers the economic incentive to use the other?

I.e. when using agile practices, the benefits of test-driven development have less economic impact than they would have on a non-agile project. True? Crazy?

Problem Number Two.

One of the mantras of agile is 'YAGNI' -- You Aint Gonna Need It -- meaning, don't waste time writing extra code on the off chance it's needed later.

Test-Driven Development (TDD), on the other, states unequivocally that it's worth writing extra code, lots and lots of extra code, up to five times as much code you'd write otherwise. The reasons for this are: it may stop bugs from escaping your desk -- and it may help out when you need to alter the design later.

Hello? Maybe just maybe YAGNI can be applied to TDD? Or do we pick and choose when YAGNI applies?

So what gives? These seem like obvious reasons why TDD and Agile should be preferred in isolation from each other, not together. Why are they so often co-practiced?

An example where TDD trumps Agile?

If building a Mars Rover, go with TDD, not agile. Because once the Mars Rover has landed on the surface you can't say "okay, let's do another iteration, and really get these features right."

An example where Agile trumps TDD?

On the other hand, if trying to develop software for a vague client, go with agile and forget TDD. There's little value in having a completely bug free system that the client will take one look at and say "y'know, I realise now that what I really want is something else altogether..."

Questions over. Your turn.

[note -- by saying "I'm not against either of these practices, but i'm certainly not a true believer" i realise i'm 'damning them with faint praise'. So be it ;-) ]

My book "Choose Your First Product" is available now.

It gives you 4 easy steps to find and validate a humble product idea.

Learn more.