Designing Minds

 Tim Morton’s been blogging up a storm about design issues, mostly, I take it, about architectural design and the environment (this link takes you to one of a blizzard of posts in the neighborhood). But architecture is hardly the only locus of design. The human world is filled with designed objects and processes. Some quite concrete, but some rather abstract.

I’m thinking in particular about computer software, which has spread its tendrils throughout the civilized and semi-civilized and hanging-on-the-edge worlds in the past half-century. The thing about software is that we don’t understand it very well. Hence it’s ‘buggy.’ Some bugs are merely annoying, but some bugs bring the system crashing down in ways that destroys hours, days, or weeks or more of work.

It’s commonplace in the software world to think that, in designing software for some particular application, you must design to the user’s view of the world. How does the user think and act? What’s the user want and desire? At this level design is a species of cognitive anthropology. But how many software engineers are trained in ethnology? What do they know about human perception and cognition – which, at best, are poorly understood.

The other day I was talking to a very experienced and very senior software designer, database architect to be more exact, who gave me a typical example. Consider a package shipping firm, such as Federal Express, UPS, or DHL. Who’s the firm’s customer? Well, to the route driver, the customer is the person or organization who receives shipment of a package and who may also turn over a package for delivery. To the clerk in a package shipping store the customer is the person who delivers a package for shipping. To the account executive the customer is the person or organization who pays for shipping, and that person may not be the person who receives the package or who turns it over to the company for delivery.

So we’ve got at least three different definitions of customer. Now, you might say that that’s a matter of mere definition. And, in a sense you’re right. But getting people to agree on ‘mere’ definitions is not easy, especially when they’re being asked to accede to a definition that doesn’t accord with their view of the world, however limited it may be. The software world is filled with such problems of mere definition.

Thus, it was not at all surprising when this architect starting talking about how one might take a Kantian view of the problem, in which one attempts to design the software to a given user’s view of it. Or, he went on, one might opt for a Platonic view, in which one attempts to design the software so as to reflect the world as it is, in essence. That’s how he thinks about the problems he faces in being a database architect. But, alas, he tells me, there aren’t many folks in the computer biz who can follow him when he talks in such terms, Kant vs. Plato. (I wonder what Nietzschean software would be like?)

And yet, at this point, we seem irrevocably committed to living in a world pervaded by software. By this stuff we don’t understand, can’t make very well, is buggy. And breaks down. Over and over and over.