Home > Articles > Programming > Java

  • Print
  • + Share This
From the author of

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.

  • + Share This
  • 🔖 Save To Your Account