TITLE: How's That Workin' For Ya?
AUTHOR: Eugene Wallingford
DATE: February 10, 2005  5:02 PM
DESC: XP is more than an agile development methodology; it's a self-improvement system.
-----
BODY:
I recently saw a statement somewhere, maybe on the XP
mailing list, to the effect that XP doesn't prevent
people who will fail from failing; it helps people
who will succeed to succeed more comfortably or more
efficiently.

I think that, in one sense, this is true.  No software
methodology can do magic.  People who for whatever
reason are unprepared to succeed are unlikely to
succeed.  And I believe that good developers can do
even better when they work in an agile fashion.

But in another sense I think that XP and the other
agile methods can help developers get better at what
they do.  If a person makes a commitment to improve,
then adopting XP's disciplines can become a <EM>better
developer</EM>.

This all came to the front of my mind yesterday as
I read a short essay over at
<A HREF="http://www.43folders.com/">
   43 Folders</A>
on
<A HREF="http://www.43folders.com/2005/02/systems_ciphers.html">
   systems for improving oneself</A>.
Merlin's comments on self-improvement systems caused
a light bulb to go off:  XP is a self-help system!
Consider...
<UL>
<LI> Successful self-help systems help a person to
     become more self-aware and to use what they
     observe to effect a more favorable solution.
<P>
<LI> Successful systems encourage simplicity and
     communication.
</UL>

Agile software methods draw on a desire to get better
by <EM>paying attention</EM> to what the process and
code tell us and then <EM>feeding that back into the
system</EM> -- using what we learn to change how we
do what we do.

Practices such as continuous unit testing provide the
feedback.  The rhythm of the test-code-refactor cycle
accentuates the salience of feedback, making it possible
for the developer to make small improvements to the
program over and over and over again.  The agile
methods also encourage using feedback from the process
to fine-tune the process to the needs of the team,
the client, and the project.

Improvement doesn't happen by magic.  The practices
<STRONG>support</STRONG> acquiring information and
feeding it back into the code.

A person is more likely to stick with a system
if it is simple enough to perform regularly and
encourages small corrections.

Merlin proposes that all successful self-improvement
systems embody...

<BLOCKQUOTE><EM>
... a few basic and seemingly immutable principles:
<UL>
<LI> action almost always trumps inaction
<LI> planning is crucial; even if you don't follow
     a given plan
<LI> things are easier to do when you understand
     why you're doing them
<LI> your brain likes it when you make things as
     simple as possible
</UL>
</EM></BLOCKQUOTE>

That sure sounds like an agile approach to software
development.  How about this:

<BLOCKQUOTE><EM>
... the idea basically stays the same: listen
critically, reflect honestly, and be circumspect
about choosing the parts that comport with your
needs, values, and personal history.  Above all,
remember that the secret code isn't hiding ...
-- the secret is to watch your progress and just
keep putting one foot in front of the other.
Keep remembering to <STRONG>think</STRONG>, and
stay focused on achieving modest improvements in
whatever you want to change.  <STRONG>Small
changes stick.</STRONG>
</EM></BLOCKQUOTE>

Any software developer who wants to get better
could do much worse than to adopt this mindset.
-----