- Reduced Time in Up-Front Design
- Refactoring Versus Up-Front Design
- Reduced Time Producing Non-Executable Documentation
- Reduced Time in Reading/Updating Materials
- Less Time Wasted Reading Inaccurate Materials
- Reduced Debugging Time
- Reduced Number of Defects
- Reduced "Mulling" Time
- Reduced Amount of Code and Increased Reuse
- In Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Less Time Wasted Reading Inaccurate Materials
If we’re following the rules of TDD, all of our tests run green all the time. This means that the specifications expressed in tests represent reality—the code does what the tests say it does. Non-executable documentation is often ambiguous, misleading, or sometimes dead wrong. Nothing other than mandate forces us to update non-executable material, so it usually doesn’t get done. Or, if it gets done, it’s done poorly. With TDD, we have the very visible incentive to keep our tests green.
I no longer trust most written design documentation. How many times have you been handed printed binders with the caveat that "they’re out of date"? We rarely do a good job of updating printed documentation. Once anything in this written documentation becomes false, developers get good at ignoring it.