TITLE: TDD and GTD: Instances of a Pattern
AUTHOR: Eugene Wallingford
DATE: August 12, 2008 4:24 PM
I once wrote that
extreme programming is a self-help system.
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
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
Getting Things Done,
or GTD. I've
never read the book
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.
on the basic concepts of GTD. Here is why GTD makes me
think of TDD:
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
Successful patterns recur. I shouldn't be surprised to
find these similarities.
- think in terms of outcomes: write a test
- take the next action: take a simple action
- review your circumstances regularly: refactor