TITLE: Agile Moments
AUTHOR: Eugene Wallingford
DATE: February 16, 2005 11:18 AM
DESC: When I read about agile software development, and write programs, and discuss ideas with colleagues, I sometimes have moments that make think, "Yes!"
-----
BODY:
When I taught a course on Agile Software Development
last semester, I fell into a habit of beginning the
first class each week with a segment called "Agile
Moments".  Think of Saturday Night Live's old
<A HREF="http://www.google.com/search?q=deep+thoughts+by+jack+handy">
   Deep Thoughts, by Jack Handy</A>,
only on a more serious plane.  I'd gather up one or
two interesting ideas I'd encountered in the previous
week from posts to the XP mailing list, blogs I'd
read, or projects I was working on.  Then I'd pull
out a provocative or entertaining quote and use
that to launch into a discussion of the idea with
my students. This seemed like a good way to share
topical information with my students while showing
them that they could enter into real conversations
about how to write programs.  It also reminded my
students that I am always reading what others are
writing about agile software, and that they could,
too.

Anyway, I've been so busy planning for
<A HREF="http://hillside.net/chiliplop/2005/">
   ChiliPLoP 2005</A>,
for which I am program chair and a Hot Topic
leader, and
<A HREF="http://www.ithaca.edu/sigcse2005/">
   SIGCSE 2005</A>,
at which I am
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2005-01.html#e2005-01-24T10_01_44.htm">
   co-leading a workshop with Joe Bergin</A>,
that I haven't been writing a lot here.  But I
do find myself having Agile Moments, so let me
share them with you.

<EM>Programming and Testing</EM>

Patrick Logan has a nice article on
<A HREF="http://patricklogan.blogspot.com/2005/02/speaking-in-objects-vs-code-complete.html">
   speaking in objects</A>,
which suggests that programming is best thought
of as a dialog with the computer.  The pithy quote
that stands out in this article is one he
attributes to Ward Cunningham:

<BLOCKQUOTE>
It's all talk until the tests run.
</BLOCKQUOTE>

We all know that's true.

<EM>Simple Design</EM>

Grady Booch is spending a lot of time in his
considerable library as hew works on his
<A HREF="http://www.booch.com/architecture/index.jsp">
   Handbook of Software Architecture</A>.
Yesterday he wrote about
<A HREF="http://www-106.ibm.com/developerworks/blogs/dw_blog_comments.jspa?blog=317&entry=72489&ca=drs-bl">
   one of his favorite books</A>,
John Gall's <EM>Systemantics</EM>.  Based on Grady's
recommendation, I just picked this book up from our
library.  Among other things, Gall argues that
successful large systems invariably come from
successful small systems.  This reminds me of agile
development's emphasis on piecemeal growth and
evolutionary design through tests and refactoring.
One of Gall's quotes captures one of the primary
motivations of the agile approaches:

<BLOCKQUOTE>
Bad design can rarely be overcome by more design,
whether good or bad.
</BLOCKQUOTE>

This points out the big risk of
<A HREF="http://c2.com/cgi-bin/wiki?BigDesignUpFront">
   Big Design Up Front</A>:
If we get it wrong, we likely have sunk our project.
It is hard to recover from a bad design.

Of course, in true Agile Moments fashion, I also
encountered a cautionary tale about evolutionary
design.  Martin Fowler warns of the risks of
<A HREF="http://martinfowler.com/bliki/AbundantMutation.html">
   Abundant Mutation</A>,
which can occur with large teams when many sub-teams
attack a common issue in different ways, or with
smaller teams when a stream of newcomers continually
join a project in mid-stream and take unfinished
code in different directions.  Martin reminds us
that "evolutionary design requires attention, skill,
and leadership".

<EM>Continuous Refactoring</EM>

Blaine Buxton recently posted a
<A HREF="http://www.blainebuxton.com/weblog/2005_02_01_archive.html#110842697885318112">
   quote</A>
worthy of being an agile slogan:

<BLOCKQUOTE>
Code removed is code earned.
</BLOCKQUOTE>

Refactoring may end up shrinking the size of your
system, but it is a <EM>net addition</EM> in the
quality of your system.  You earn the ability to
add the next requirement more easily, as well as
the ability to understand the program more easily.

Blaine's quote reminded me of my favorite quote
about the joys of refactoring, which showed up
in a
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2004-08.html#e2004-08-02T08_27_48.htm">
   blog entry</A>
I wrote long ago:

<BLOCKQUOTE>
The only thing better than a 1000-line of code
weekend is a minus 1000-line of code weekend.

<P ALIGN="right"> -- Brian Foote
</BLOCKQUOTE>

Brian could make a fine living as a writer of
slogans and jingles!
-----