TITLE: Software in Negative Space AUTHOR: Eugene Wallingford DATE: April 07, 2005 7:49 AM DESC: We design the software we see. Could we instead design what we don't see? ----- BODY: Drawing on the Right Side of the Brain 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. a freehand rendition of the Japanese character 'ma' 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 as

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.

Software 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? -----