T2D or not T2D

The  hidden costs of  meeting moronic ideals

Recently, I've had the distinct misfortune of working with an advocate of test driven development.

Now, generally this is not a bad thing. There is a case to be made for testing, certainly. My extreme and utter distain for TDD however, is rekindled anew when I see how inefficient it realy is. (The developer is a cool guy, this is not a reflection on him, just on the TDD philosophy)

Have you found Jesus?

I often hear the same old sales pitch: 'you will save so much time later' or 'you write better code'. Bull Shit.

People who advocate TDD  have either never had to cost a project for development, or have never had to pay for some other insipid ass-hat to dev with it.

It won't save you time later.  All you get for having a 'good' test set is the guilt-induced obligation to maintain it.

It will cost you a lot of time. Often when you can least afford it, like two days before a deadline.

When I develop an application, I often don't know where it will end up. That's agile development. I jump in and code and the app will bring itself into existence. Obviously this is an oversimplification of the whole process, but I want to put it in stark contrast to planned development.

Yin

In planned development, developers make implementation decisions that drive the stream of application growth ever closer to the well defined end goal, in as straight a line as possible. The cost of planning is upfront, and the incentive is there to not deviate, because it negates all the planning.

I compare this to building a tunnel to get to the other side of a mountain. It's startlingly direct and incrementally very expensive in effort. Developers are often forced to use the biggest hammer they can find to bludgeon the code toward the end goal.

Yang

In the other corder is agile development. Developers guide the code into being. Coaxing it toward some end goal.

In the analogy, this is akin to building a curving mountain pass that follows the contours of the land *. Doing it the scenic way is incrementally cheap and you can always change your mind and follow a different curve at almost any point.

To milk this lovely construction analogy some more. With agile development, you get to see the view from the top of the mountain and often see outcomes and possibilities that you would never have even considered if you were stuck in a tunnel. So fuck tunnels.

What ?

What has this got to do with testing?  Well, a lot and almost nothing at the same time.

When you plan software ahead, you can write tests to evaluate against the planned outcome. If the tests pass, then presumably you have not fucked it all up. I'd stop short of saying it's guaranteed to work, because all a passing test proves is that a test passes.

Writing tests beforehand puts a goalpost down that you then code towards. So there goes all agile intentions and benefits. If you still want agile development,  you have to embrace writing and rewriting tests until ...

You go north. You are in an cubicle. 

The letters 'TDD' are scrawled in feces on the wall. 

A dead developer lies in the corner.

This applies on every scale. If you want to test methods, then you need to know those methods before you have developed the code. So you need to  go and guess at what the solution might be, without the benefit of experience of actually solving the problem. And then ? Well then you anally mauraude your code until that quick guess is the solution, because fuck, we have a test that needs to pass!

I shall now coin the phrase: Goatse Driven Development! **

Not testing methods, just testing requests? Same shit, different scale. What if in the solving of the problem you realise a complete new controller actually solves it elegantly. Instead, you are stuck with a test for your 3s hair-brained guess from before, that you now have to make work.

This is where many TDD ass-hats jump up and scream that you need to just adapt your test. Really ? "Adapting" it just a euphemism for "rewrite your tests at every turn in the agile development process".

That's insanely expensive, on every level. Good developers change their minds about almost every single choice they make, because they question themselves. You are beating that doubt out of them, and making them stick with the first crap that comes into their head, just to avoid writing that test one more time.

So inconclusion:

Say 'TDD' again. Say 'TDD' again, I dare you, I double dare you motherfucker, say TDD one more Goddamn time!


* This is an awesome analogy, like a hotdog
** or, I guess Goal Driven Development. But fuck that. ***
*** oooh, double entendre! Score!