I started college as an architecture major. In the
first year, architecture students took two courses
each semester: Studio and Design
Communications Media. The latter had a lofty
title, but it focused on the most basic drawing
skills needed in order to communicate ideas visually
in architecture. At the time, we all considered it
a freehand art class, and on the surface it was.
But even then I realized that I was learning more.
The textbook for DCM was Betty Edwards's
Drawing on the Right Side of the Brain.
It is about more than drawing as a skill; it is
also about drawing out one's creativity. Studying
this book, for the first time I realized that what
we do in life depends intimately on what we see.
Often, when people try to draw a common object,
such as a chair, they don't really draw the chair
in front of them but rather some idealized form,
a Chair, seen in their mind's eye. This chair
is like a Platonic ideal, an exemplar, that
represents the idea of a chair but is like no
chair in particular. When the mind focuses on
this ideal chair, it stops seeing the real chair
in front of it, and the hands go onto cruise
control drawing the ideal.
The great wonder in Edwards's book was that I
could learn to see the objects in front
of me. And, in doing so, I could learn to see
things differently.
Drawing on the Right Side of the Brain
introduces a number of techniques for seeing an
object, for the first time or in a new way, with
exercises aimed at translating this new vision
into more realistic depictions of those items on
paper or canvas.
I recently found myself thinking again about one
of the techniques that Edwards taught me, in the
realm of software. Alan Kay has often said that
we computer computer scientists focus so intently
on the objects in our object-oriented programming
that we miss something much more important: the
space between the objects. He speaks of the
Japanese word ma, which can refer to the
"interstitial tissue" in the web of relationships
that make up a complex system. On this view, the
greater value in creating software lies in getting
the ma right.
This reminds me of the idea of negative
space discussed in Edwards's book. One
of her exercises asked the student to draw a chair.
But, rather than trying to draw the chair itself,
the student is to draw the space around the chair.
You know, that little area hemmed in between the
legs of the chair and the floor; the space between
the bottom of the chair's back and its seat; and
the space that is the rest of the room around the
chair. In focusing on these spaces, I had to
actually look at the space, because I don't have
an image in my brain of an idealized space between
the bottom of the chair's back and its seat. I
had to look at the angles, and the shading, and
that flaw in the seat fabric that makes the space
seem a little ragged.
In a sense, the negative space technique is merely
a way to trick one's mind into paying attention
to the world in a situation when it would prefer
to lazily haul out a stock "kitchen chair" image
from its vault and send it to the fingers for
drawing. But the trick works! I found myself
able to draw much more convincing likenesses than
I ever could before. And, if we trick ourselves
repeatedly, we soon form a new habit for paying
attention to the world.
This technique applies beyond the task of drawing,
though. For example, it proves quite useful in
communicating more effectively. Often, what
isn't said is more important than what
is said. The communication lies in the idea-space
around the words spoken, its meaning borne out
in the phrasing and intonation.
The trigger for this line of thought was my
reading an
entry
in Brad Appleton's blog:
... the biggest thing [about software design] that I learned from [my undergraduate experience] was the importance of what I believe Christopher Alexander calls "negative space", only for software architecture. I glibly summarized it asSoftware designers could use this idea in different ways. Brad looks at the level of design and code: Leave room in a design, rather than overspecifying every behavior and entity that a program may need. But this sense of negative space is about what to leave out, not what to put in. The big surprise I had when using Edwards's negative space technique was that it helped me put the right things into my drawings -- by focusing on their complement. I often think that the Decorator design pattern embodies negative space: Rather than designing new classes for each orthogonal behavior, define objects as behaviors with receptacles into which we can plug other objects. The negative space in a Decorator is what makes the Decorator powerful; it leaves as many details uncommitted as possible while still defining a meaningful behavior. I suppose that the Strategy pattern does the same sort of thing, turned inside out. Maybe we can take this idea farther. What would it be like to design a program not as a set of objects, or a set of functions, but as Kay's ma? Rather than design actors, design the spaces in between them. Interfaces are a simple form of this, but I think that there is something deeper here. What if all we defined were an amorphous network of messages which some nebulous agents were able to snatch and answer? Blackboard architectures, once quite common in artificial intelligence, work something like this, but the focus there is still on creating knowledge sources, not their interactions. (Indeed, that was the whole point!) Even crazier: what it would be like to design software not by focusing on the requirements that our users give us, but on the "negative space" around them? Instead of adding stuff to a concoction that we build, we could carve away the unwanted stuff from a block of software, the way a sculptor creates a statue. What would be our initial block of granite or marble? What would the carving feel like? Whether any of these farfetched ideas bears fruit, thinking about them might be worthwhile. If Alan Kay is right, then we need to think about them. Edwards's negative space technique makes for a powerful thinking strategy. Like any good metaphor, it helps us to ask different questions, ones that can help us to expose our preconceptions and subconscious biases. And it could be of practical value to software designers, too. The next time you are stumped by a design problem, focus on the negative space around the thing you are building. What do you see? -----There is no CODE that is more flexible than NO Code!
The "secret" to good software design wasn't in knowing what to put into the code; it was in knowing what to leave OUT! It was in recognizing where the hard-spots and soft-spots were, and knowing where to leave space/room rather than trying to cram in more design.