TITLE: Agile Moments: TDD and the Affordances of Programming
AUTHOR: Eugene Wallingford
DATE: July 09, 2009  7:59 AM
DESC: 
-----
BODY:
I recently ran across a link to a Dan Bricklin article
from a few years ago,
<A HREF="http://www.bricklin.com/wontprogram.htm">
   Why Johnny can't program</A>.
(I love the web!)  Bricklin discusses some of the
practical reasons why more people don't program.
As he points out, it's not so much that people
<EM>can't</EM> program as that they <B>won't</B>
or <B>choose not</B> to program.  Why?  Because
the task of writing code in a textual language
isn't fun for everyone. What Bricklin calls "typed
statement" programming fails all of Don Norman's
principles of good design: visibility, good
conceptual model, good mappings, and full and
continuous feedback.  Other programming models do
better on these counts -- spreadsheets, rule-based
expert system shells, WYSIWYG editors in which users
generate HTML through direct manipulation -- and
reach a wider audience.  Martin Fowler recently
talked about this style, calling it
<A HREF="http://martinfowler.com/bliki/IllustrativeProgramming.html">
   illustrative programming</A>.

I had an agile moment as I read this paragraph from
Bricklin about why debugging is hard:

<BLOCKQUOTE><EM>
One of the problems with "typed-statement" systems
is that even though each statement has an effect,
you only see the final result.  It is often unclear
which statement (or interaction of statements) caused
a particular problem.  With a "Forms" or direct
manipulation system, the granularity is often such
that each input change has a corresponding result
change.
</EM></BLOCKQUOTE>

When we write unit tests for our code at about the
same time we write the code, we improve our programming
experience by creating intermediate results that help
us to debug.  But there's more.  Writing tests helps
us to construct a conceptual model of the program we
are writing.  They make visible the intended state of
the program, and help us to map objects and functions
in the code onto the behavior of the program at run-time.
When we take small steps and run our tests frequently,
they give us full and continuous feedback about the
state of our program.  Best of all, this understanding
is recorded in the tests, which are themselves code!

In some ways, test-<EM>driven</EM> programming may
improve on styles where we don't type statements.
By writing tests, we participate actively in creating
the model of our program.  We are not simply passive
users of someone else's constraint engine or inference
engine.  We construct our understanding as we construct
our program.

Then again, some people don't need or want to write the
reasoning component, so we need to provide access to
tools they can use to be productive.  Spreadsheets did
that for regular folks.  Scripting languages do it for
programmers.  Some people complain about scripting
languages because they lack type safety, hide details,
and are too slow.  But the fact is that programmers are
people, too, and they want tools that put them into a
flow.  They want languages that hit them in their
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2004-09.html#e2004-09-28T17_08_59.htm">
   sweet spot</A>.

Bricklin concludes:

<BLOCKQUOTE><EM>
From all this you can see that the way a system requires
an author to enter instructions into the computer affects
the likelihood of acceptance by regular people.  The more
constrained the instructions the better.  The more the
instructions are clearly tied to various results the
better.  The more obvious and quickly the results may
be examined the better.
</EM></BLOCKQUOTE>

TDD does all this, and more.  It makes professional
programmers more productive by providing better cognitive
support for mental tasks we have to perform anyway.
If we use TDD properly as we teach people to program,
perhaps it can help us hit the sweet spot for more
people, even in a "typed statement" environment.
-----