Communications of the ACM

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.