Test Driven Development, or TDD has quite a few different connotations; in fact, at our recent TDD horror stories event, the definition of TDD itself was split down the middle. Half of the attendees defined TDD as writing a test before writing any code and the other half defined it as writing tests for anything that could break (thus, not necessarily writing a test first).

Of course, TDD stresses tests and by actually writing them, TDD enables a more robust design– so much so that often TDD is thought of as Test Driven Design. Accordingly, TDD facilitates a more maintainable design through the notion of tests. These tests force you to think about the behavior of the code and how to ensure it works as intended. More often than not, code bases influenced by TDD are relatively un-complex and arguably quite simple.

Code that is un-complex and simple is easier to change than code that exhibits opposite traits like complexity and brittleness. What’s more, because code written with TDD in mind is backed by tests, any changes that break the code are quickly spotted. In essence, TDD code is easier to change and easier to fix.

But TDD isn’t about easier changes either– at least not directly. No, TDD is all about speed. When teams execute consistently with TDD in mind, features are produced faster. Faster features means shorter time to market. Shorter time to market means greater change of obtaining more customers. Best of all, that speed to market is backed by a safety net of tests that enable rapid change in the same amount of time (if not quicker).

TDD is all about speed. Fixing defects that could have been spotted during development is a waste of time and money. Companies that are developing software without early testing will undoubtedly be stuck with a code base that can’t change easily– and they’ll be beaten by a company who is more nimble and quick– because they build solid code from the start with TDD.