TITLE: Agile Thoughts: Humans Plus Code
AUTHOR: Eugene Wallingford
DATE: November 20, 2008  8:22 PM
DESC: 
-----
BODY:
Courtesy of Brian Marick and his
<A HREF="http://www.exampler.com/blog/2008/11/14/agile-development-practices-keynote-text/">
   Agile Development Practices keynote</A>:

<BLOCKQUOTE><STRONG>
Humans plus running code are smarter than humans plus time.
</STRONG></BLOCKQUOTE>

We can sit around all day thinking, and we may come up
with something good.  But if we turn our thoughts into
code and execute it, we will probably get there faster.
Running a piece of code gives us information, and we can
use that feedback to work smarter.  Besides, the act of
writing the code itself tends to make us smarter, because
writing code forces us to be honest with ourselves in
places where abstract thought can get away with being
sloppy.

Brian offers this assertion as an assumption that underlies
the agile software value of working software, and specifically
as assumption that underlies a guideline he learned from
Kent Beck:

<BLOCKQUOTE><EM>
No design discussion should last more than 15 minutes
without someone turning to a computer to do an experiment.
</EM></BLOCKQUOTE>

An experiment gives us facts, and facts have a way of
shutting down the paths to fruitless (and often strenuous)
argument we all love to follow whenever we don't have
facts.

I love Kent Beck.  He has a way of capturing great ideas
in simple aphorisms that focus my mind.  Don't make the
mistake that some people make, trying to turn one of his
aphorisms into more than it is.  This isn't a hard and
fast rule, and it probably does not apply in every
context.  But it does capture an idea that many of us
in software development share: execucting a real program
usually gives us answers faster and more reliably than
a bunch of software developers sitting around
pontificating about a theoretical program.

As Brian says:

<BLOCKQUOTE><EM>
Rather than spending too much time predicting the future,
you take a stab at it and react to what you learn from
writing and running code...
</EM></BLOCKQUOTE>

This makes for a nice play on Alan Kay's most famous
<EM>bon mot</EM>, "The best way to predict the future is
to invent it."  The best way to predict the future of
a program is to invent it: to write the program, and
to see how it works.  Agile software development depends
on the fact that software is -- or should be -- soft,
malleable, workable in our hands.  Invent the future
of your program, knowing full well that you will get
some things wrong, and use what you learn from writing
and running the program to make it better.  Pretty
soon, you will know what the program should look like,
because you will have it in hand.

To me, this is one of the best lessons from Brian's
keynote, and well worth an Agile Thought.
-----