For Speed and Certainty TDD Wins

As software grows, Test Driven Development beats Legacy Development in terms of speed and certainty.

With Legacy Development (manual testing)

1. I get some new requirements. 
2. I modify the application code. 
3. I step through the code in my head.
4. I run the application in a few scenarios.
Repeat steps 2 - 3 or 4 until everything works as expected
Repeat steps 1 - 4 until all requirements are met

With Testing Legacy Code (write tests after application code)

1. I get some new requirements. 
2. I modify the application code. 
3. I modify the test code.
4. I run the tests.
Repeat steps 2 - 4 until all tests pass
Repeat steps 1 - 4 until all requirements met

With Test Driven Development (write test(s) before application code)

1. I get a new requirement.
2. I encode the requirement as a test.
3. I modify the application code.
4. I run the tests.
Repeat steps 2 - 4 until all tests pass
Repeat steps 1 - 4 until all requirements encoded

Compare the three approaches in terms of speed and certainty.

Speed

All three approaches get slower over time.  The software grows and verifying all requirements takes more time.  

Doing this manually is clearly slowest. (Computers run code faster than I do.) But writing tests takes time too.  The question is which takes more time? Writing tests? Or manual testing?

The answer is that the cost of writing tests stays roughly constant.  However, the cost of manual testing goes up with the amount of code.

The question becomes: when does the time taken to manually verify code exceed the time necessary to write unit tests which can automatically verify the code?  After a week?  A month?  After the second developer comes on?  For applications of significant size, TDD wins.  

Certainty

The most uncertainty is with manual testing and the least is with test driven development.  

In manual testing (legacy development), the programmer elects to run some test scenarios mentally, and some manually. It is based on judgment calls, and is nebulous.

With unit testing of existing code, the parity between tests and implementation is difficult to verify. It is mentally taxing to determine which tests to write after the implementation is done. Is all code covered?  Even with 100% code coverage, not all requirements may be covered.

With test driven development there is less ambiguity.  A requirement is encoded as a test. Then, just enough implementation code is written to meet the requirement.  Parity.  Balance.  Certainty.