TITLE: Design as Choice
AUTHOR: Eugene Wallingford
DATE: August 01, 2006  7:16 PM
DESC: 
-----
BODY:
Last week, I quoted Bob Martin on the
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2006-07.html#e2006-07-27T13_31_25.htm">
   interplay between design and building</A>:

<BLOCKQUOTE><EM>
You always have to design something before you build it.  The
question is:  "How much do I have to design before I build?"
... the act of building is *part* of the act of design....
</EM></BLOCKQUOTE>

To many people, this sense of design is heresy.  They prefer
a more formal definition, one that makes clear a distinction
between between design and implementation, and analysis and
design.  Even in a day where iterative models of software
development have replaced the waterfall model in the minds of
even the most traditional software engineers, many people still
think of the phases of development as very different.

Agile software developers seek to iterate more quickly through
the phases of software development, in large part because of
what Martin reminds us: we learn too much about our design
from writing code to wait very long to begin writing code.
Likewise, we learn too much from our design and coding about
how well we understand our problem to wait very long to begin
designing and writing code.

So, what is the best definition of design for us to use in
our work, and with our students and new hires?  Folks who see
the phases of software development as Major Events to be seen
as separate activities are most likely to give Major Definitions
to the phases.  But I've learned a lot about design from folks
who have more pragmatic takes on software development.

Sometime last year, the members of a mailing list I'm on
discussed the definition of design.  Jim Coplien and Grady Booch
gave very thorough definitions of design, both the verb (the act
of designing) and the noun (the artifact produced).  Both of their
definitions incorporated the idea of a system and its behavior,
related to the forces that exist in the system's intended
environment.  The thing I liked best about Booch's definition
was how it managed to account for the scientific side of design,
where empiricism and experiment help us to make optimal decisions
in a large search space, as well as the artistic side, where
science leaves enough degrees of freedom to enable clever and
elegant decisions.

Whatever else design is, it is about the <STRONG>choices</STRONG>
we make while building things.  Some of the features of a system
are required by the customer, and others are driven by the
technologies that we use, including the programming language.
The rest of the system is determined by the developer.  This is
how James Noble characterized design in our e-mail discussion:
the decisions we make that determine the rest of the system.

By the way, Noble's definition reminds us just how important it
is not to use an overly restrictive programming language when we
build systems.  Such a language makes too many decisions for us
upfront, without regard the problem we are solving or the environment
in which the system will live.  Choosing such a language surrenders
too much freedom, too much possibility, too soon.

Once we get to the point of seeing design as being about choices,
and without any predisposition to create a complex definition in
order to distinguish design in some formal way, we can get to my
all-time favorite one-line definition of design.  This definition
is courtesy of Ward Cunningham, whose gift for simplicity I have
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2005-11.html#e2005-11-04T08_34_32.htm">
   extolled before</A>:

<BLOCKQUOTE><EM>
Design is your choices that stick.
</EM></BLOCKQUOTE>

This brings us back to the fundamental truth in the agile approach
captured by Robert Martin in the passage above:  Not all of our
choices will stick, and we need to learn which will and which
won't as quickly as possible, from whatever sources we have
available.  And that includes the program itself.
-----