The TDD cycle is test, code, refactor, (repeat) and then ship. TDD implies development that is driven by testing, specifically that means understanding requirements and then writing tests first before developing or writing code. My natural inclination is a philosophical bias in favor of TDD; I would like to be convinced that there are other approaches that now work well or even better than TDD so I have asked this question. What are examples of perfectly acceptable approaches that NOT test driven development? I can think of plenty approaches that are not TDD but could be a lot more trouble than what they are worth ... it's not moral judgement, it's just that they are cost more than they are worth ... the following are simply examples of things that might be ok as learning exercises, but approaches I'd find to be NOT acceptable in serious production and NOT TDD might include: Inspecting quality into your product -- Focusing efforts on developing a proficiency in testing/QA can be problematic, especially if you don't work on the requirements and development side first ... symptom of this include bug triaging where the developers have so many different bugs to deal with it, it is necessary to employ a form of triage -- each development cycle gets worse and worse, programmers work more and more hours, sleep less and less, struggle to keep going in death march until they are consumed. Superstition ... believing in things that you don't understand -- this would involve borrowing code that you believe has been proven or tested from somewhere, e.g. legacy code, a magic code starter wizard or an open source project, and you go forward hacking up a storm of modifications, sliding FaceBook Connect into your the user interface, inventing some new magic features on the fly (e.g. a mashup using the Twitter API, GoogleMaps API and maybe Zappos API), showing off your cool new "product" to a few people and then writing up a simple "specification" and list of "test cases" and turning that over to Mechanical Turk for testing.