- 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
Reduced Time Producing Non-Executable Documentation
Part of the effort in producing designs ahead of producing code is documenting those designs. When doing significant up-front design, we create a nice thick binder of UML diagrams and other design-oriented documents. Our idea is to be able to drop off these binders on the desk of each programmer, and they’ll all know exactly how to build the desired system.
We expend a lot of time and effort in producing these documents. Sometimes we wallow in lengthy discussions and arguments about the design. Worse, we often suffer a lot of angst over the aesthetics of the document. We argue over trivialities. We change the document often throughout its lifetime.
When doing TDD, I no longer retain paper artifacts that represent the design. Suppose we have two systems: a profusely documented system, complete with lots of UML diagrams and comments; and a system constructed properly using TDD but with neither comments nor UML. Given the choice of which to work on, I’ll always go with the test-driven system. It’s a lot easier for me to understand, navigate, and maintain.