This “Theory Object” business — I’m trying to work out what it might mean through practice, through the activity of making things. As Bruce Sterling said in his wonderfully rabinical talk at SXSW just the other day, “A Theory Object is a kind of Theory Object.” It’s got that geeky recursion, like GNU — GNU is Not Unix.
I’m going to try and parse that for a spell — A Theory Object is a kind of Theory Object.
I think there’s a good reason for a Theory Object being a kind of Theory Object, and it’s about design patterns for design itself, another recursion. But this isn’t a recursion puzzle land for the sake of geeky fun. There are important stakes in this approach, that operate at a number of levels, but mostly around the area of creating a world that won’t ruin itself any more than it already has. How do you do that? Maybe there’s a design pattern that’ll help — an approach to making things that matter.
Jystar, a computer science grad student down at UC Irvine, wrote a post on the topic of Theory Objects that made me think about the “frameworks” used to make things, like software-based systems. In the software engineering idiom, where I have some stakes and a bit of background, one often hears about frameworks or design patterns as models to help get things done. They’re super useful, and they help move from an idea to an articulation of that idea because some of the larger pieces of the software design as well as the small glue have been throught through in the form of “design patterns” and such all.
Design patterns create standard frameworks for solving problems. They provide a common language for sharing approaches to work , which makes getting things made easier. You can convey a whole lot of information by referring to patterns when your colleagues know what you’re talking about.
Engineer 1: “I’ll be using the “Chain of Responsibility” pattern to address this problem”
Engineer 2: “Right. Good choice. That one works well for this sort of problem.”
This is what Yahoo has to say about Design Patterns, it’s nice and succinct:
Patterns are optimal solutions to common problems. As common problems are tossed around a community and are resolved, common solutions often spontaneously emerge. Eventually, the best of these rise above the din and self-identify (whoa..) and become refined until they reach the status of a Design Pattern.
from [http://developer.yahoo.net/ypatterns/lifecycle.php]
Design Patterns have a great cloud of evocative idioms swirling around them — “lifecycle”, for instance. It’s an evocative, suggestive, word with great tangible connotations. It seems promising to consider because physical things also have lifecycles. Unfortunately, those lifecycles often run from design to rubbish heap, and we need more well-designed Things, not more rubbish heaps.
Check out the canonical “Design Patterns” book from those software desparado’s referred to as “The Gang of Four”
It’s right there in the title. This should be required reading for all near-future Spime dudes and doodlers and tinkerers and thinkers: Design Patterns: Elements of Reusable Object-Oriented Software. Did you hear that? Reusable Objects. Software recycles. Awesome.
The Gang of Four has lovely, semantically rich names for their patterns — they’re really worth mentioning a sample of them:
* abstract factory pattern
* builder
* adapter
* bridge
* decorator
* facade
* flyweight
* chain of responsibility
* mediator
* memento
* observer
* visitor
from wikipedia Design Patterns
These are from software but they’re so tangible and weighty and Thing-y. These should be able to translate to other practices, and jump disciplinary boundaries. Most practices have Design Patterns â— I might even argue that all do, but I’m against totalizing assertions most of the time. Think about a social practice. Web design, fashion design, aircraft design, barbequing, knitting, photography. They’ve all go their patterns — their approaches, stylings, “professionalized” ways of doing things.
It’s a good thing that this Design Pattern thing exists. Just imagine a world in which there were no Design Patterns, which is like imagining a world in which there were no technical languages for specific practice idioms.
Suppose doctors while operating couldn’t say,
“I’m going to perform a Wortley Cross Retraction to get that malignancy.”
Suppose they could only be vague and fumble about for suitable vocabulary,
“I’m going in after that, you know..weird kind of fuzzy looking goo there — give me one of those scoopers”
Same with the guys screwing wings to aircraft fusalages. If it weren’t for specialized, technical jargony idiolects, I’d never get on an airplane. Ever. Can you see these guys,
“I’m going to, like..tighten this thing to that thing you’re standing on. What do you think — finger tight or should I lean on this wrench with, like..all my might?”
The world just wouldn’t work right.
The “Theory Object” is a kind of design pattern for design itself. It’s about thinking by creating, and revealing the trail of discovery in the process of making things. And it has this recursive characteristic — not just revealing the process in the documentation or the manual or the “write-up” or the “post-mortem”, but actually embedding all of this within the designed Thing itself.
This is what software engineers call “reflection” or “discovery” or “introspection” — a style of design patterns in which the software can tell you about itself while it’s running. This is great stuff for Internet of Things things, like Blogjects and Spimes. Why? Because we need to know about them while they’re doing their Thing. We want them to tell us where they came from, or how they operate or how to use them without digging up a manual. They should be “discoverable”, we should be able to “introspect” them and have them “reflect” their ontological aura to the rest of the room.
Things, networked physical objects, should be able to do this as a matter of course.
Java has something called “JavaBeans”, which is an important kind of pattern, if only for what it sets out to achieve:
The JavaBeans API provides a framework for definining reusable (there’s our friend), embeddable, module software components.
from Java in a Nutshell
It’s a great concept, this introspection, reflection, discovery and these “Beans” — and one of the great instances of a legible vocabulary to describe the pattern. Reflection. Discovery. Introspection. Awesome. Makes me pround to be part-engineer, this one.
But, of course, JavaBeans, reflection and discovery are the patterns that work really really well in software design practices. They make a lot of difficult problems easier, they create a standard approach that faciliates reuse. They provide approaches to things like open-source software design. How? By providing ways to comprehend how a bit of code works — either through patterns (“oh — i get it. this guy used the visitor pattern. right. i can now extend this functionality because i know how this one sub-component works. it’s legible to me because i know the pattern”), or through the more voodoo-like discovery, reflection and introspection.
The Theory Object is a way of making things — of doing design — that reveals the process of design, all of Latour’s inscriptions, all the iterations all the trials and failures and wrong turns. Why? To make things public in this way reveals the “made”, “hand-crafted” social character of things. And it’s better, politically and for better futures, to know that something was made this way rather than that way, why such decisions are made, and by whom.
By explicating the design process we see how making things, particularly science and technology things, is a social activity. And when we see science and technology activities as a social endeavor it is easier to have conversations about making one thing rather than another. And because science and technology play such an integral, crucial role in us imagining what the future can be, it is empowering to know that Things don’t have to be the way they are. Things can be different — both the material instantiation of some idea some researcher “gets” and the future that those material Things make possible.
That’s empowering. Knowing that lots of decisions are made and knowing why they’re made and opening up the design process, particularly for science and technology Things. Knowing that Things can be different can empower us to imagine a future we want, rather than the one that Dow Chemical or DARPA wants for us.
Here, finally, is the Theory Object recursion I was talking about: the Theory Object is the design pattern and the instantiation. It is a way to design — a pattern — and the outcome of adhering to that design pattern. This point is brought to bear in some neat things that near-future objects will be able to do, many of which Bruce Sterling is well-positioned to consider. These near-future Things will be able to tell us and other cohabitants in the Internet of Things about themselves — that will make them better neighbors and participants in the Internet of Things. They’ll just be well-behaved and coherent — it’s simple. Bruce Sterling’s right — widgets and gizmos are out. Some form of self-descriptive, introspective, reflective, Spimey Things are in.
In the Internet of Things, Things that can’t tell us about them will be like junk DNA — no apparent use, probably a relic. Just hanging around for the ride. Detritus from a past evolutionary swerve. it’ll be like finding a Campbell’s soup can from an era before they had those nutritional labels and wondering — what’s in this thing?
The Theory Object is supposed to reveal the process of design — capturing all the little bits and pieces, all of the inscriptions that brought the thing into being, all of its “DNA”, the parts manifests, CAD drawings, functional APIs. The Theory Object also reveals the design itself in its instantiation. So, my camera, say, can not only take pictures, but it can tell other cameras what it has taken pictures of and share those pictures by exchanging flickr! usernames — that’s right, cameras, not just humans, will have flickr! accounts.
If there’s a next time, I’ll try to muddle through why this Theory Object —design pattern stuff is really, really important, why Things that work with this pattern matter. It’s real. It’s important. I’m not meshuggener.
Technorati Tags: theory object