... .  .    .       .joeberkovitz.com

Software Models, Software Shadows

April 11, 2006 on 1:12 am | In Programming, Uncategorized |

Software engineers like to talk about models, and build them. We build object models, process models, and, when we’re feeling especially clever, model models or metamodels. I think there’s a collective sense in the profession that modeling is a healthy and useful step in understanding… er… whatever it is that we’re modeling. Come to think of it, just what are we modeling when we do all this stuff? Or, to step back even further, what is modeling?

Here’s a rough definition of modeling that I believe many engineers would agree with: “The selection of a set of symbolic representations of real-life entities, relationships, and operations”. It sounds straightforward enough, although we all know the practice can be difficult. We look at real life, identify some things which are going on, and decide how we will map a set of symbols to those things in a hard-edged fashion amenable to some computing. In doing so, we’ll make some choices that we think best reflect “real life”. We won’t get all of it right, but we’ll get some of it right — the part of interest.

Well… I think I don’t believe in that definition any more. Of course, I don’t doubt the utility of modeling (which I practice constantly) as a discipline for getting useful things done. What I doubt is our own innocent notions of what we’re actually doing in the process. If we reexamine the nature of modeling, we might surprise ourselves. And with that surprise comes a chance we might slip out of some of our mental constraints and create much better software.

As we go about modelling our world, we typically make some assumptions:

• There are objective real-life entities, relationships, etc. that exist independently from any software one might build.
• Human language (itself a set of symbols) can be used to describe and define these objective things more-or-less unambiguously.
• We can map those human language descriptions and definitions to symbols that we use in writing software — classes, attributes, methods, messages, and so on. The result will be that relations which hold in the real world, will also hold in our symbolic representation of that world.
• If we’ve been careful, the software will support human actions and intentions around the very real-life things we started with.

In summary, we think of ourselves as fitting software to an objective world that bears symbolic representation, with language as an intermediate waypoint on the way to objects, classes, and so on. As a practical payback, our software will fit into that world, when it’s done. What’s wrong with that?

Pretty much all of it.

First, I don’t believe that there is an independent, objective reality “out there” waiting for humans and their software to describe it. We don’t have access to that reality, although I do think that something of the sort obviously exists. The raw material for our modeling efforts is not the real world, but our perception of that world as manifested in our consciousness.

This is not some subtle philosophical point, but a big fat 10-ton anvil dropping out of a cartoon sky. When we “model” something, we usually make the mistake of thinking that we are reflecting something “out there”. What we’re really doing is reflecting something “in here”: the reality inside our heads, what we as conscious beings work with. And what is “in here” is not a neat bunch of taxonomies and graphs, but some biologically rooted, ill-behaved, interesting stuff — stuff that sometimes exhibits behavior similar to taxonomies and graphs, but is utterly different underneath. We are going to have to understand that stuff much better if we want to build software that fits our nature. Research is uncovering some very surprising truths about the way we as humans work with categories of objects and concepts. And while the practices of user-centered design have gone far to improve the usability and utility of the software that gets built, human-centered thinking usually stops at the programmer’s threshold. As well it might: our whole approach is inadequate. A crude tool like class membership can’t capture the gradation, metaphor and metonymy of everyday human concepts.

In my kitchen at home, there are two places where kitchen utensils are stored. One of them is a jar, and the other is a drawer. Somehow or other we’ve reached a practical concensus on what belongs where. The jar mostly has long or extended things and the drawer has mostly flatter and sharper things. However, there are a few non-obvious cases. The pie slicer, although it’s got a long handle and isn’t sharp, definitely goes in the drawer. It just seems right, because it slices something. If it slices, it’s metaphorically sharp.

Like software, human language is a formal symbolic system. But in spite of its having formal rules and syntax, a clear mapping of word symbols to things “out there” in the world is just a non-starter of an idea. It does not fly. Words map to complex sets of states of our internal consciousness, not to the world. And those states do not stand in neat taxonomic relations to each other based on their attributes. Pie slicers belong in the drawer.

Similarly, a software program is a kind of extended language that inherits the fuzzy, funky nature of human categorization and transports it into a realm of algorithms. But the determinacy of the algorithms does not imply that these programs into a neat, clean manipulations of some representation of reality. The operations may be formal, but the input and output are interpreted by people. A software program is a kind of mechanized Mad Lib, supplying a framework into which our biologically rooted ideas can be plugged, yielding biologically rooted results.

Where do we go with this? I only have a few terribly inadequate ideas right now:

• Let’s investigate metamodels that might come closer to capturing the nature of human concepts, and think about how they might be employed in the context of computation. The standard UML models of classes and objects are impoverished when compared to the things we do in our heads every day. George Lakoff’s fascinating book Women, Fire and Dangerous Things sets out some clear pointers as to the kinds of things we might consider.
• Let’s beware of attempts to reductively define human cognition as the things that computers do well or which we can program conveniently. Just because we can write a limited parser or a planning algorithm doesn’t mean we’re actually learning about how our minds work, or that we’re applying that learning.
• Let’s recognize that when we make a “software Mad Lib”, we’re putting constraints on what can fit into it, and think about what those constraints will mean to us and to our users. When we model something as a “Document” or an “AirlineReservation”, we’re setting up a complex bunch of word-associations for ourselves, the engineers, that we will carry with us, and which will ultimately be expressed in code that affects the users of the system and future programmers who might change what we wrote. Modeling is all about choosing words, which in turn is really about choosing sets of mental states. Let’s be mindful of the consequences for our own thinking as we choose those states.