I had a very interesting discussion at GOTO Chicago with the awesome Corey Haines, software journeyman and founder of the Code Retreat movement.
We were talking about the “Spike and Stabilize” pattern, and whether it was a good idea to suggest (as I have) that experienced TDDers can skip TDD under situations of flux and high uncertainty. I still maintain that you have to be really good at TDD to write spikes and stabilize them, and agree with Corey that most developers will get more traction from throwing away their prototypes once they have feedback, and start again “properly”.
However, I think the skill of being able to take existing, messy code, clean it up, and bring it under test, is hugely important.
Developers aren’t born knowing how to do TDD effectively. New developers will always be coming into our industry, and they’ll always be making a mess until they learn how to make things clean. If you can write your tests first, that’s absolutely fantastic! But if you can’t – or if someone on your team can’t – then being able to tidy up the code, and being able to show others how to do it, is IMO even more important than getting it right in the first place… and it’s not just novice devs who make the messes, either. We’re all human.
So if you can’t write tests first, at least write tests second. Then try writing them first next time.