A Crayon for the Mind
In a 1994 article from the New York Times [HOLLAND] music reviewer Bernard Holland noticed
an odd thing. He had gone out and purchased a brand-spanking new
compact disc of a favorite album, one that he had owned for 40 years
on a vinyl record.
The new CD sounded brilliant, crisp and clear—just as he had
remembered the record. So he went down to the basement and
found the 40 year old record.
It sounded awful. Not at all as he remembered it. It was muffled,
tinny, muddy, you name it.
The title of the article is “The LP: A Crayon For the Mind”, and
Mr. Holland goes on to speculate that it is the mind of the listener
that had filled in all the details missing from the original record.
Filled in exactly what was needed—no more and no less, as evidenced by
the correlation between the mentally revised record with the pristine
perfection of the compact disc.
Marshall McLuhan, in the 1964 book “Understanding Media” (the “Medium
is the Message” book) [MCLUHAN]
spoke of “hot” and “cool” media. Contrary to what
you would expect that to mean, both television and the CD are
classified as “hot” media. The listener/viewer isn’t involved.
You are force fed content at a very high bit-rate without any
imagination or effort on your part. The media gives. You take.
That is all.
By contrast, books, and probably the net are considered “cool” media.
They require some level of audience participation.
This differentiation is why Mr. Holland called the LP “the crayon
for the mind”. Since most of the details were muffled or inaudible,
the mind had to actively “color in” what was missing—and did
A Cool Design
The goal of a good object-oriented design is to be a “cool”
design—that is, one that requires the engagement of the
reader in order to make sense.
Too many designers and methodologies seem to push the notion of
over-specifying a design. Provide too many details and the
design becomes “hot”. Think really hot. Think melt down.
The more explicit the design is, the less freedom you (or anyone else)
have to implement it. The code becomes a brittle slave to the
design; inflexible, and software rot can start to set in.
But on the other hand, you can’t leave important details out of the
design, lest different implementors implement them differently!
Or just plain wrongly.
So how do you create a design specification that works like the LP?
Implicit in that it is lacking important details, but
structured enough so that every reader fills in the details the
The correct balance between explicitness and implicitness is the
trick. I can’t pretend to say “here is a formula” that will always
work, because it won’t. A lot depends on your experience, the
nature of the system being constructed, and the environment
(both technical and political) that you are working in.
But there is one method that seems to work well that I can share
The idea is design with philosophies, which I use here to
mean a very high level abstraction. A philosophy in this context
is a statement by the designer of how a thing should behave.
Think of a CRC card (Class-Responsibility-Collaborators), but
without the the class or collaborators. That is, think of a
responsibility that one or many classes may have in the system.
Codify a philosophy of dealing with it. This could be something
as simple as “whoever allocates a resource will de-allocate it”,
“whoever starts a transaction will end it”,
or as implicitly complex as “data gathered from any source
for any purpose will be posted to the blackboard”. But it is
a guiding philosophy, one that transcends any particular class,
Guidelines like these can be relied on by developers to also
be true—system invariants, if you will. Given this overall
structure, a developer can “fill in” the details and be sure of
fulfilling the overall contracts of the system.
And it can turn out just as perfect as the CD—and just as
satisfying as vinyl.
Holland, B. “The LP: A Crayon for the Mind”,
New York Times Sunday July 24, 1994, page 30.
McLuhan, M. “Understanding Media, The Extensions of Man”,
MIT Press, 1964.