Thread by @RonJeffries

OK, strong article to follow but for now, listen up.
There's this idea, the red/green/refactor thing, the never write a line of code not required by a failing test thing, the evolve the design based on the test and code plus your lovely imagination thing, the keep it clean thing.

I say "idea". You can see many ideas there already.

There is a name, TDD, Test-Driven Development or Test-Driven Design, that is applied to that bunch of ideas. We want to draw a bright line around the ideas that /are/ TDD, and to keep out the ones that are not TDD.

Yeah, no, we can't do that. Ideas are mushy and they flow one into another and they smear all over each other, and they change from something sensible to something stupid right before your eyes.

Still, we'd like to do that and for now I'll try to do that.

Imagine that the right ideas can be corralled and the wrong ones kept out. We'll call that imaginary thing, just now, "Pure TDD" or PTDD for short.

You are not authorized to use that name to mean something. It doesn't mean anything. It only kind of means something, some ideal.

Many of us "have" that idea, in its ideal form, WHICH CANNOT BE SHARPLY DELINEATED, and we also have it in the form in which we use it from moment to moment and day to day. That way is soft and mushy. I want to say that it is wise and graceful and elegant, but no. Soft and mushy.

Sometimes we refactor on red. Sometimes we add code that no test needs. (Sometimes it's code that no one will ever need.) Sometimes we have an idea for the code and we just type it in.

Watch us on a given day, and there will be moments when you want to shout "THAT'S NOT TDD!!!"

Well, it isn't PTDD, but it is the TDD that exists, the TDD that is, the TDD that lives in our hearts and minds, living as best it can in the muck and mire that is the mind of its hosts.

It's Real TDD, and it is both more and less than PTDD.

It's less because we do write code without a failing test and we do write code entirely speculatively and we for the life of us can't figure out how to test CSS or Second Life physics, and we just go ahead and build things anyway.

But it's more than PTDD because PTDD infects everything we do.

In the simplest form, if we're not writing tests, we often go in tiny steps and compile or run the code frequently, long before the whole thing works.

PTDD infected us with the habit of tiny steps.

A little harder to see is that, when we can't figure out how to test the GUI, we code so that there's as little logic as possible in the GUI, putting as much of the logic as possible where we /can/ test it.

PTDD pushes us toward testing as much as possible.

Even harder to see is that we begin to learn, slowly and imperfectly, where we really need TDD style and where we can safely let it slide.

Sometimes we're even right about that.

PTDD taught us to better see our strengths and weaknesses.

At a certain stage of learning, we want to know just what the hell things are. We want them cut and dried. We want them defined. Some of us want "engineering", imagining that engineering is cut and dried. (It isn't.)

We don't get that. We won't get that.

Software development is, I want to say always, a creative activity. Creative activities aren't cut and dried, they are pragmatic, dynamic, sometimes clear as day, sometimes just plain mysterious.

Pure TDD is this nice simple clear set of a few central ideas. Folks think that they aren't there yet but one day they'll totally get TDD and all will be clear.

That's not what happens. It's not even what /should/ happen.

What should happen, and if we work at it with our minds open and running full blast, is that we'll get better and better at quickly producing software that works well enough, and is designed well enough, to do the job.

We can't do that with Pure TDD. It's just a simple tool.

We do it with a thoughtful human mind, versed in Pure TDD, and in thousands of other ideas from software, from science, from the humanities, that somehow, in a fashion unique to each of us, we bring to bear on producing a good product.

TDD isn't just "write no code without a failing test". It's also "know when to write code without a failing test", and "know when to just pour the code out into the keyboard", and "know a thousand other things".

You may want me to tell you when not to do TDD. I can't do that. You have to learn when not to do TDD. Odds are, you're already not doing it much of the time and you're still alive.

You can learn to use TDD well and as you learn that, you will learn when not to. Your learning will be different from mine. One of you will even crack that damn CSS problem someday.

Do things and learn from them. That's all there is.