What is the opposite of TDD?

Question

Test Driven Development (TDD) and its benefits are well defined. The same can be said for practices like Behavior Driven Development (BDD). Each represents a software development technique that advocates greater discipline before you start coding.

What, then, is the convenient acronym for the "unstructured" approach to development?

I've seen "TAD" (Test After Development) used on occasion, but that still implies testing is being done. Has anyone seen (or does anyone want to invent) an acronym for the "code it as you go" approach to development? I'm looking for the TDD/BDD/xDD equivalent for the type of development we've all done where we simply write code and release.

(Clearly, there is plenty of room for "comedy" here, so let's refrain from "n00b Driven Development" and the ilk.)

[UPDATE]

Lots of very good responses. Ultimately, I think the ideas of "Development Driven Development" or "Idea Driven Development" best answer the question. Where in TDD you're trying to pass tests and in BDD you're trying to satisfy behavior, in "unstructured" development, you're really only driven by trying convert an idea in to code.

Clearly, no right or wrong answer, but a good collection of opinions here. Hopefully this resource will be useful for others trying to clearly capture the "definition" of development in absence of process.

Answer 1

I don't know about an acronym, but what you're referring to is typically called Cowboy Coding.

Cowboy Coders are programmers who write code according to their own rules.

The Cowboy Way:

• The speed with which I can hack something together determines my worth
• People who need comments in order to understand my code are too dumb to be working with me
• People who ask me questions about my code are too dumb to understand it, and (therefore) are too dumb to be working with me
• Other people's code is just crappy, but mine is self-descriptive and beautiful
• Exploiting a compiler-dependent language feature to save a line of code is "elegant"
• Other people on my team cause all of the bugs; I'm the one that fixes them
• My code is never at fault, always perfect, and I don't make mistakes
• Since my code is never at fault, I don't need to test it thoroughly, if at all
• Since my code is always perfect, it never needs to be refactored no matter how long it's been in the codebase or how much has changed around it
• Since I never make mistakes, I can yell at anyone else who does
• Since my code is perfect, if the program crashes due to unexpected data, it's the user's fault for entering bad data.
• Since my code is perfect, if the program fails after a minor machine configuration change, it's the sysadmins fault for changing it.
• Since my code is perfect, if the program runs too slowly, it's the managements fault for not providing a faster machine.

Answer 2

FDD

Faith Driven Development.

Because you need to pray your project works on every release.

Answer 3

AD(D)D - Attention Deficit (Driven) Development

In which you:

• randomly work on whichever portion of the application attracts your attention at the time
• work on features for whichever user squawks the loudest (until someone else squawks louder)
• run down rabbit trails in the code, forget the path you took to get there, and come out at some completely different place and solving some completely different problem
• "refactor" code by changing its behavior without a solid grasp of what it is actually supposed to do or whether it still works when you are finished - but if it doesn't, you might get around to fixing it if somebody squawks loud enough

Answer 4

I'd tend to agree with Pavel but would go further and call it:

Development Driven Development

Development driven without any clear motivation is development for the sake of development. In TDD, you develop to satisfy tests. In BDD, you develop to establish some behaviour. In Development-driven development, you develop because you're a developer and that's what you're paid to do.

Answer 5

MaDD -- Manager Driven Development.

It already takes you longer than you estimated just to code the real product--now you want to spend more time writing tests which never get released?!?!