Prove It With Code

While reading Scott Rosenberg's "Dreaming in Code", I was reminded of a reference to William Shakespeare's "A Midsummer Night's Dream" Jim McCarthy's "Dynamics of Software Development"; Theses, The Duke of Athens opens the first scene in the fifth act with the following:

"Lovers and madmen have such seething brains,
Such shaping fantasies, that apprehend
More than cool reason ever comprehends.
The lunatic, the lover, and the poet,
Are of imagination all compact.
One sees more devils than vast hell can hold;
That is the madman. The lover, all as frantic,
Sees Helen's beauty in a brow of Egypt.
The poet's eye, in a fine frenzy rolling,
Doth glance from heaven to earth, from earth to heaven;
And as imagination bodies forth
The forms of things unknown, the poet's pen
Turns them to shapes, and gives to airy nothing
A local habitation and a name.
Such tricks hath strong imagination"

Whether you are a lunatic hacker, code-lover or code poet it is important to remember that programming is similar to the poet's pen. Software design is a mental exercise. We apply abstractions and models to express what we intend to build and how we we'll build it. But unless we prove our  luscious designs with working code, they are mere castles in the air.
Scott Ambler gives some good advice in "Agile Modeling":

"You've developed a sketch of an HTML page for accepting billing address information? Code it and show the resulting user interface to your users for feedback. You've developed a UML sequence diagram representing the logic to implement a complex business rule? Write the testing code, the business code, and run the tests to ensure that you've gotten it right"

Code is our best tool to prove that our designs reflect the business needs. If you do Test Driven Development (TDD) you are in a good position to use code to prove your designs, because TDD shortens the feedback loop and provides concrete feedback on your design. TDD is such a valuable tool that you should consider using it to both evolve and validate your designs in parallel. Because high-cohesion and loose-coupling are prerequisites for a testable application, evolving your code with TDD as the driver leads to better designs. This approach uncovers many facets of your "castle" that probably weren't visible when it was airy nothing.