TITLE: TDD is a Means for Delaying Intuition
AUTHOR: Eugene Wallingford
DATE: April 08, 2019 11:55 AM
DESC: 
-----
BODY:
 In
<A HREF="https://medium.com/conversations-with-tyler/tyler-cowen-daniel-kahneman-economics-bias-noise-167275de691f">
   one of his "Conversations with Tyler"</A>,
 Tyler Cowen talks with Daniel Kahneman about intuition and its
 relationship to thinking fast and slow.  According to Kahneman,
 evidence supports his position that most people have not had
 the experience necessary to develop intuition that is good
 enough for solving problems directly.  So he thinks that most
 people, including most so-called experts, should slow down.

<BLOCKQUOTE><EM>
 So I think delaying intuition is a very good idea.  Delaying
 intuition until the facts are in, at hand, and looking at
 dimensions of the problem separately and independently is a
 better use of information.
</EM></BLOCKQUOTE>

<BLOCKQUOTE><EM>
 The problem with intuition is that it forms very quickly, so
 that you need to have special procedures in place to control
 it except in those rare cases...
</EM></BLOCKQUOTE>

<BLOCKQUOTE><EM>
 ...
</EM></BLOCKQUOTE>

<BLOCKQUOTE><EM>
 Break the decision up.  It's not so much a matter of time because
 you don't want people to get paralyzed by analysis.  But it's a
 matter of planning how you're going to make the decision, and
 making it in stages, and not acting without an intuitive certainty
 that you are doing the right thing.  But just delay it until all
 the information is available.
</EM></BLOCKQUOTE>

 This is one of the things that I find most helpful about test-driven
 design when I practice it faithfully.  It's pretty easy for me to
 think that I know everything I need to implement a program after
 I've read the spec and thought about it for a few minutes.  I mean,
 I've written a lot of code over the years...  If my intuition tells
 me where to go, I can start right away and have the whole path ahead
 of me in my mind.

 But how often do I really have evidence that my intuitive plan is
 the correct one?  If I'm wrong, I'll spend a bunch of time and write
 a bunch of code, only later to find out I'm wrong.  What's worse,
 all that code I've written usually ends up feeling like a constraint
 within which I have to work as I try to dig myself out of the mess.

 Writing one test at a time and implementing just the code I need to
 pass it is a way to force my intuitive mind to slow down.  It helps
 me think about the actual problem I'm solving, rather than the
 abstraction my expert brain infers from the spec.  The program
 grows slowly along side my understanding and points me in the
 direction of the next small step to take.

 TDD is a procedure I can put in place to help me control my
 intuition until the facts are in, and it encourages me to look at
 different dimensions of the problem independently as write the code
 to solve them.
-----