TITLE: Agile Themes: Organic Planning and the Cost of Change
AUTHOR: Eugene Wallingford
DATE: November 30, 2009 10:04 PM
DESC: 
-----
BODY:
My previous agile theme, on
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2009-11.html#e2009-11-27T12_40_03.htm">
   organic planning</A>,
has implications for how we design and implement
solutions -- for making decisions that "stick".
Derek Sivers recently used an apocryphal story about
<A HREF="http://sivers.org/walkways">
   walkways</A>
to express a similar principle:

<BLOCKQUOTE><EM>
So <B>when should you make business decisions</B>?
When you have the most information, when you're at
your smartest: <B>as late as possible</B>.
</EM></BLOCKQUOTE>

My first thought was that this principle follows from
adaptive planning, but that confuses causal order with
temporal order.  Sivers's conclusion assumes that we
are "at our dumbest at the beginning, and at our
smartest at the end".  This is the same context in
which organic planning applies.  It is not always the
context in which we work, but when it is, then late
binding -- lock-in -- is valuable.

One of the reasons I like to use dynamic programming
languages is because they give me late binding in two
dimensions: at programming time and at run time.  When
I'm coding in a domain where I'm not very smart at the
outset and become smarter with experience, late binding
in programming time seems to make me more productive.
Allowing my programs to make decisions as late as
possible means that I can imbue my code with the same
sense of committing at the right time to an object or
function, not sooner.

Implicit in this notion is that our designs and programs
will change as we move forward, as we learn more.  In
the domain of new business ideas, where Sivers works,
change and growth are almost unavoidable.  Those of us
who program in interesting new domains experience a
similar pattern of learning and evolution.  If change
is going to happen, the question becomes, should we
load our change into the beginning or end of our
development process?  Seth Godin
<A HREF="http://blog.reemer.com/post/194456167/what-you-do-for-a-living-is-not-be-creative-what">
   knows the answer</A>,
whether you work in software, business, or any other
creative endeavor:

<BLOCKQUOTE><EM>
You must thrash at the beginning,
because thrashing at the beginning is cheap.
</EM></BLOCKQUOTE>

Some people object to the notion of change as "thrashing",
because it sounds unskilled, unprofessional, even
undignified.  Godin uses the term to indicate the kind
of frantic activity that some organizations undertake
as they near a deadline and are trying desperately to
finish a product that is worthy of delivery.  In that
context, "thrashing" is a great term.  That sort of
frantic activity is not wrong in and of itself -- it
reflects the group's attempt to incorporate all that
it has learned in the course of development.  The
problem is in the timing: when too many sticky decisions
have been made, changing a product to incorporate what
we have learned is expensive.

Rather than try to fight against the thrashing, let's
instead move it to the beginning of the process, when
change is less expensive and when are still figuring
out which of our decisions will stick over the long-term.
This is how reactive planning, change, and late binding
can come together to make us more effective developers.
-----