TITLE: Quick and Wrong and Fast and Slow
AUTHOR: Eugene Wallingford
DATE: December 08, 2011  4:23 PM
DESC: 
-----
BODY:
I've been reading a lot about Daniel Kahneman's new book,
<EM>Thinking, Fast and Slow</EM>.  One of the themes of
the book is how our brains include two independent
systems for organizing and accessing knowledge.  System
One is incredibly fast but occasionally (perhaps often)
wrong.  It likely developed early in our biological
history and provided humans with an adaptive advantage
in a dangerous world.  System Two developed later, after
humans had survived to create more protective surroundings.
It is slow -- conscious, deliberative -- and more often
right.

One reviewer summarized the adaptive value of System One
in this way:

<BLOCKQUOTE><EM>
In the world of the jungle, it is safer to be wrong and
quick than to be right and slow.
</EM></BLOCKQUOTE>

This phrase reminded me of
<A HREF="http://allankelly.blogspot.com/2009/02/requirements-better-off-being-generally.html">
   an old post by Allan Kelly</A>,
on the topic of gathering requirements for software.  The
entry's title is also its punch line:

<BLOCKQUOTE><EM>
You are better off being generally right than precisely
wrong.
</EM></BLOCKQUOTE>

These two quotes are quite different in important ways.
Yet they are related in some interesting ways, too.

It is easier to be fast and <EM>generally</EM> right
than to be fast and <EM>precisely</EM> right.  The
pattern-matching mechanism in our brains and the
heuristics we use consciously are fast, but they are
often imprecise.  If generally right is good enough,
then fast is possible.

Attempts to be slow and precisely <EM>right</EM> often
end up being slow and precisely <EM>wrong</EM>.  Sometimes,
the world changes while we are thinking.  Other times,
we end up solving the wrong problem because we didn't
understand our goals or the conditions of the world as
well we thought we did at the outset.

Evolution has given us two mechanisms with radically
different trade-offs and, it turns out, a biological
bias toward quick and wrong.

When I talk with friends who dislike or don't understand
agile approaches, I find that they often think that
agile folks overemphasize the use of System One in
software development.  Why react, be wrong, and learn
from the mistake, when we could just think ahead and
do it right the first time?

In one way, they are right.  Some proponents of agile
approaches speak rather loosely about Big Design Up
Front and about You Aren't Gonna Need It.  They leave
the impression that one can program without thinking,
so long as one takes small enough steps and learns
from feedback.  They also leave the impression that
everyone should work this way, in all contexts.
Neither of these impressions is accurate.

I try to help my skeptical friends to understand how
a "quick and (sometimes) wrong" mindset can be useful
for me even in contexts where I could conceivably plan
ahead well and farther.  I try to help them understand
that I really am thinking all the time I'm working,
but that I treat any products of thought that are
not yet in code as contingent, awaiting the support of
evidence gained through running code.

And then I let them work in whatever way makes them
successful and comfortable.

I think that being aware of the presence of Systems
One and Two, and the fundamental trade-off between
them, can help agile developers work better.  Making
conscious, well-founded decisions about how far to
think ahead, about what and how much to test, and
about when and how often to refactor are, in the end,
choices about which part of our brain to use at any
given moment.  Context matters.  Experience matters.
<EM>Blindly</EM> working in a quick-and-generally-right
way is no more productive approach for most of us
than working in a slow-and-sometimes-precisely-wrong
way.
-----