> When the code is working and you’re ready to move onto the next phase, then you can work on making the code pretty, readable, well-documented and tested. While this flies in the face of concepts like test-driven development...

I disagree that writing "shit code that still works" and TDD have to be mutually exclusive. In fact, if I'm going to go the "just get it done" route, I will almost (but not always) try to set up a few tests for it.

Because nothing sucks harder then going back to crap code and trying to decipher what it's doing. If it's crap code, then it's likely non-orthogonal code, which means changing it will likely break something...etc. etc. Tests help me do the refactoring later.

And, also, how do I know that my shit-code-just-works actually works? Sometimes, it's helpful to write a kind-of-shitty-test to at least verify that it kind of works, if not perfectly.