The Unreasonable Effectiveness of TDD

Such people, if they exist, are heretics and kulaks, enemies of responsible software development, and should be liquidated as a class.

I'm not one of the people you're looking for, but like so many things, a flexible mix based on the character of the work at hand is usually most effective. Sometimes (sometimes) you doodle to think, sometimes you code to think: how do you write a failing test for doodling?

FWIW I was writing what were effectively unit tests, and doing them essentially first or all but first, in the late eighties before (I think) TDD even had letters, but it didn't rule my life. I was chastised for being too new and not good enough to carve the whole monolith at one sitting. I did what I needed to anyway.

I'm one of those depending on the team I'm working on.

As a rule, if I would rather my colleague not to write code at all, I likely prefer them not to do TDD either.

Bad code is never fun to maintain. With bad TDD code, you just get twice as much per feature.

Well I've had projects where I've written a lot of tests before really having the overall design right (without realizing it of course) and ended up wishing I'd waited a bit before writing the tests, because I had to redo a lot of them and it slowed down the process. Of course if you just do things right from the start this won't happen, but I often don't.

> How long must we endure programming cults with no science behind them?

Until someone invents a cost-effective way to do science on programming techniques. I'm not holding my breath, because we're talking about workplace habits, communication through code, and team dynamics, which is an altogether different beast than mathematics or physics.

TDD aside, I'm personally interested in any testing approaches that apply to user interaction.