TITLE: TDD and GTD: Instances of a Pattern
AUTHOR: Eugene Wallingford
DATE: August 12, 2008  4:24 PM
DESC: 
-----
BODY:
I once wrote that
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2005-02.html#e2005-02-10T17_02_34.htm">
   extreme programming is a self-help system</A>.
This generalizes pretty well to other software methodologies,
too.  As we step away from developing software to personal
hygiene, there is an entire ecosystem around the notion of
<A HREF="http://en.wikipedia.org/wiki/Life_hack">
   life hacks</A>,
self-help for managing information and combatting data
overload.  Programmers and techies are active players in
the lifehacking community because, well, we love to make
tools to solve our problems and we love self-help systems.
In the end, sometimes, we spend more time making tools and
playing with them than actually solving our problems.

One of the popular lifehacking systems among techies is
David Allen's
<A HREF="http://www.davidco.com/">
   Getting Things Done</A>,
or GTD.  I've
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2008-06.html#e2008-06-04T14_07_40.htm">
   never read the book</A>
or adopted the system, but I've read about it and borrowed
some of its practices in trying to treat my own case of
information overload.  The practices I have borrowed feel
a lot like XP and especially test-driven development.  Maybe
that's why they appeal to me.

Consider
<A HREF="http://www.43folders.com/2008/08/08/outcome-based">
   this post</A>
on the basic concepts of GTD.  Here is why GTD makes me 
think of TDD:

<OL>
<LI> think in terms of outcomes:  <STRONG>write a test</STRONG> </LI>
<LI> take the next action:  <STRONG>take a simple action</STRONG> </LI>
<LI> review your circumstances regularly:  <STRONG>refactor</STRONG> </LI>
</OL>

This is not a perfect match.  In GTD, a goal from Step 1
may require many next actions, executed in sequence.  In
TDD, we decompose such big goals into smaller steps so that
we can define a very clear next action to perform.  And in
GTD, Step 3 isn't really refactoring of a system.  It's
more a global check of where you are and how your lists
of projects and next actions need to be revised or pruned.
What resonates, though, is its discipline of regular review
of where you are headed and how well your current 'design'
can get you there.

It's not a perfect match, but then no metaphor is.  Yet
the vibe feels undeniably similar to me.  Each has a mindset
of short-term accountability through tests, small steps to
achieve simple, clear goals, and regular review and clean-up
of the system.  The lifehackers who play with GTD even like
to build tools to automate as much as they can so that they
stay in the flow of getting things done as much as possible
and trust their tools to help them manage performance and
progress.

Successful patterns recur.  I shouldn't be surprised to
find these similarities.
-----