tools are fast, but not too fast—not so
fast that they encourage laziness. Not
so fast they encourage writing programs rather than designing programs
and running programs rather than
thinking about programs. This raises
some questions:
˲Should we consider deliberately
introducing delays? Should the delays
be on the order of seconds? Minutes?
Hours?
˲ Would there be different kinds of
delays for syntax issues versus operational or logical issues?
˲ Should the delay be based on the experience level of the programmer? If so,
how does experience affect the delay?
There is only one criterion that
should determine how we should experiment and how much we should
think: Which approach will allow us to
learn most efficiently?
effort and Learning
The putative goal of systems development is the production of code that
“works” just as the putative goal of a
college education is to obtain a degree. These obvious targets mask the
true purpose of both activities which
is to learn. We can print up a degree
certificate in minutes and we can
create code pretty much as quickly
as we can type. Creating code that
does what is needed requires first
learning what is needed and learning is always an active and effortful
endeavor. If powerful tools allow us
to coast at a low energy state they can
shortcut the learning process altogether. This is true of programmers,
of college students, and of college students studying programming.
Computer Game
I have sometimes thought the manual
computer simulation we played with
pieces of paper, pretending to be a
PLAN assembly language program, was
so interesting and informative that it
could be made into a fun board game.
Just kidding.
Phillip G. Armour ( armour@corvusintl.com) is a senior
consultant at Corvus International Inc., Deer Park, Il,
and a consultant at Qsm Inc., mclean, Va.
the idea for this column came from a series of discussions
with Dave berque ( dberque@depauw.edu), professor and
chair of computer science at DePauw university, to whom
I would like to express my thanks.
Copyright held by author/owner(s).
stance in a larger framework. So Thinking is more aligned with higher-level
abstractions and global knowledge.
Thinking encourages understanding-in-the-large and this usually makes for
better systems design.
faster = slower?
As well as encouraging unplanned experimenting, faster development tools
may paradoxically increase the time
to complete programming tasks. They
may do this by encouraging a large
number of small iterations where the
learning increment is minimal, instead of a small number of thoughtful
iterations where we learn a lot. So if
faster might be slower, would slower
speed things up?
There are two forces at work here.
One is the cost of experimenting, the
other is the cost of all those iterations.
As development tool speed increases,
clearly it costs less and less to play with
a problem. This is shown in the accompanying figure by the blue bars. When
the turnaround time is very long, it is
usually too expensive to consider experimenting unless Thinking has come
to a complete dead end. As turnaround
time drops it is likely there is a threshold where Experimenting becomes
much more attractive. The threshold is
probably related to the perceived effort
required using the two approaches.
At the same time, all the iterations
generated by Experimenting have a
cost that is rising gradually (shown by
the red bars). With 100% Thinking,
there may only be a single iteration that
proves the thinking is correct. As Ex-
perimenting becomes less costly and
more impromptu many of the experi-
mental iterations may either eliminate
specious dead-ends or may not expose
any new knowledge. So while the itera-
tions might not cost much, they may
also be low-value in terms of learning.
And we tend to do a lot of them.
When Thinking departs the scene,
Experimenting turns into hacking.
Here the programmer may not even
have an idea of what to look for (or even
what he or she is looking at), not having thought through the problem at all.
In this case, provided the system does
not actually crash, an iteration might
be considered “successful”—after all,
it did “work.” But we do not learn much
from it.
This hypothesis infers there might
be a “sweet spot” where development
faster development
tools may
paradoxically
increase the
time to complete
programming tasks.
the cost of experimenting versus the cost of iterations.
Extremely
Slow
Very
Slow
Slow Somewhat
Slow
Average Somewhat
Fast
Fast Very
Fast
Extremely
Fast
C
os
t
Speed of Environment
Cost of Experimenting
Cost of Iterations