Test Driven Development is widely accepted as the core tool for responsible software development practice. But when does flexing the TDD muscle hurt more than it helps?
In a high-intensity, fast paced work environment (like a startup), you can get serious speed gains by knowing when to put away the TDD toolset and to and revisit it later on.
What should we do when code is intentionally built to be short lived? What if there’s risk in building the feature itself? Or if a feature is an experiment with customers? Is it worthwhile taking the time to TDD?
We take a look at when TDD is no longer a necessity for building good code.