This nicely describes the process and some advantages of TDD. I think it skates over what repels some programmers: the amount of ceremony and typing in that process. If you want to hack something up quick you aren't going to start by typing up

    object MiddleOutNumberSorterSpec extends Specification with ScalaCheck {

      "MiddleOutNumberSorter" should {
        "reject even number counts and throw an exception" in { }
        "return a list of the same length as the count specified" in { }
        "produce 3 numbers in the correct order" in { }
        "produce 5 numbers in the correct order" in { }
        "produce 15 numbers in the correct order" in { }
      }  
    }

A friend of mine basically quit his job over this issue at a TDD-only startup, so he said. I need to write up a post about what I do instead.

(To be fair, in classical TDD you only write one test to start.)

Thanks for the comment, much appreciated. I guess I'm not that familiar with what repels some developers as I don't recall ever feeling that repulsion towards TDD myself.

With regard to hacking something up quickly, I see no issue with this. I spike code all the time to prove a point or try out something new. If it's worthy of putting into production I'll engage in that 'ceremony' you mention. Though, theres not much that's ceremonial about it :)