Jon Udell: Hi, this is Jon Udell, and today's podcast is an interview with Steve Burbeck. If you follow web services, you may know Steve as one of the authors of the UDDI specification. He's been the Director of Computing and Statistics at the Linus Pauling Institute of Science and Medicine, co-founded a start-up that pioneered Smalltalk for the IBM PC, worked at Apple Computer in object-oriented development tools and also was VP of Development and Operations at Knowledge System Corp, again doing object-oriented design and consulting. Nowadays, Steve's retired from IBM, where he spent about 10 years working on object technology and then in IBM research on adaptive and self-configuring systems. We got together to talk about an unpublished paper of Steve's on the topic of multicellular organisms and what they may be able to teach us about managing complex information systems. Steve, you've written this essay about complexity and multicellular computing. Why don't you give us a sense of, first of all, where that comes from, in terms of your background, both in IT and with life sciences, and then we can get into where you think it can go and should go.
Steve Burbeck: OK. Well, the where it comes from is, oddly enough, related to object-oriented stuff and Smalltalk.
Jon: Doesn't seem odd to me.
Steve: Well, it does seem odd to a lot of people, because an awful lot of people who are involved are not steeped in object-oriented analysis and design and don't see the computing world as a whole bunch of collaborating objects. If you do see the world as a whole bunch of collaborating objects, then it's not a big leap to say hmm, that's a little bit like a whole bunch of collaborating cells in a biological organism that are busy sending messages.
Jon: So, given your deep background in Smalltalk, that would be an obvious way for you to think about things. Smalltalk is just a kind of soup of objects that message one another, right?
Steve: Yes. In the early days of it, in, I've forgotten, '72 or so, Alan Kay wrote a paper talking about objects and at that time he started envisioning that every object was a separate computer. Of course, that's not even physically possible. Well maybe it is today, but it certainly hasn't been physically possible until quite recently, and it wasn't at all possible in a single CPU, which was what Smalltalk really developed in. But that was one of the original ideas, that they would be asynchronous, completely independent, messaging each other. But anyway, some of the people early on in Smalltalk were thinking along these lines and voila, somewhere around the late '90s it occurred to me that with the internet and all these computers talking together and sending little packages of whatever, HTML or whatever around, that we're there. That it's doing sort of what Alan Kaye originally envisioned Smalltalk to be doing, in a very odd way. It certainly wasn't Smalltalk or object-oriented, but it has a lot of similarity.
Jon: It's a very seductive analogy, but it's also probably a dangerous one in some respects, if we're not really clear about what that means in terms of software systems, as opposed to biological ones.
Steve: Although it is even more dangerous to not think about it at all, because we are getting viruses and all sorts of crap on the internet, as a result of not thinking about this issue. So I don't know which is worse, but I do know that it's a lot harder to try and figure out what an architecture should be, because these collaborating systems of objects or computers or cells are mind bogglingly complex.
Jon: So you've carved out, I'm not going to say recommendations, but anyway, a set of areas for future development, so why don't we run through what those are.
Steve: The four fundamental metaphors, or analogies, between what I see going on in multicellular computing, by that I mean highly networked computing, with all sorts of machines doing their little bit. The four basic principles that seem to me to transfer across well enough to make it worth thinking about them are specialization, which sounds trivial, I'll get into it in a minute, the notion that messaging cannot and must not include executable code. It's just too dangerous. So, in effect, object-oriented messaging, or the messages, the meaning of the messages is determined by the receiver is the fundamental point, although that's called polymorphism but in cellular systems, it's just a fact of life. Multicellular organisms do not send code around.
Jon: What would be an example, if they did, what would be an example of that?
Steve: Well, in soups of single celled organisms, in pond water and that kind of stuff, they do. They pass little bits of DNA around and in effect share behavior. But that behavior is sort of chemistry behavior; how to metabolize some new pollutant in the water and stuff like that. So in single cell systems, passing code around does make sense. It's just that in a multicellular system, the code is viruses, basically, and that's exactly what we're seeing in the internet.
Jon: So you're saying that in the multicellular world, there was at one time code sharing and it was selected against?
Steve: You mean in biological?
Jon: Yeah.
Steve: Yeah. Well, who knows? That is my speculation. I guess the answer is yes, because the earliest kind of multicellular organisms weren't specialized in the sense of one single sperm and egg getting together and creating an organism in which every cell in the organism has the same DNA. It was stuff called biofilms, which is like the scum on rocks in a stream or your dental plaque or pond algae or things like that, where they do specialize temporarily, to collaborate in a film. But they are still single celled organisms and they do still have mechanisms to pass around DNA the way they would if they were free floating in water. So yes. Maybe I went too far into the biology there, but the point is yes, the first stage of multicellularity, where it's a whole bunch of cooperating single cell organisms, something like the web today, they did still pass around DNA. Presumably, it was selected against, because all of the full blown multicellular organisms don't do it, but that's a deduction. We can't prove it.
Jon: So message passing is an adaptive thing.
Steve: It's adaptive in the sense that a cell can't be hijacked by a protein message, or an HTML message if it's a computer, because the receiver, this is the polymorphism again, the receiver determines what it is going to do when it receives that message, and not the sender. Hijacking is when the sender determines what's going to happen, which is what viruses do.
Jon: So this is a justification for a strict message passing communication strategy in networked computing.
Steve: Right. And if you just look at what's happening in the real world, it doesn't take much justification. You allow a code to go around and boxes get hijacked.
Jon: OK.
Steve: So anyway, the third principle...
Jon: Wait, what was the second?
Steve: The second is message passing. The first is specialization. That when you go multicellular, you don't just collect together a whole bunch of general purpose boxes that could do anything that happened at this moment to be doing just the right thing in this multicellular collaboration. Although that is what the biofilm world does. They specialize. Secondly is the message passing, which means polymorphism, which means the receiver determines the semantics. Third is an odd one which is subtle. The only name for it is stigmergy, which comes out of the study of social insects -- ants, termites, and things like that.
Jon: And this is the way in which behavior is made persistent in the surrounding environment, right? Or the interaction between environment and behavior.
Steve: Right. So the insects are the best way to put it. They build an anthill or a termite mound or a bee's honeycomb and all that kind of stuff. And in the process of building that, the things they do passes on information to other ants, termites, whatever, in the passive environment, by laying down trails of pheromones and that kind of stuff. And the general notion is that there is a persistent structure that lives over time and space and that information left on it by the actions of whatever cells or insects later influences the behavior or other cells and insects, and that process is called stigmergy, which is an awkward name.
Jon: It's an awkward name and it's an obscure scientific phenomenon on the one hand, but on the other hand, it's completely obvious, I think, to everybody, that that's exactly what the web is to us right now.
Steve: Yes, absolutely. Well, the web, yes I guess that's true. Things in the web, such as a Wiki, is an absolutely obvious stigmergy structure. The Linux source code is another obvious stigmergy structure. Databases are stigmergy structures that we all deal with in that one computer puts some data in the database, other computers search it and act differently according to what they find, so the database becomes a stigmergy structure.
Jon: And, well, I'd argue that it does apply to the web as a whole, because exactly the power of Google is reflecting our own behavior back to us, right?
Steve: But without Google it was a pretty useless stigmergy structure, it's just so big. But yes, Google is taming it, or not just Google, but searching, and a lot of behaviors like that are taming it such that the entire web becomes a stigmergy structure. Absolutely. So the point in the paper that I make is that we think that multicellular organisms are thought of as defined by the cells, but they're really defined by the stigmergy structure. The human body, for instance, with the exception of some nerve cells, all of the cells regenerate. They don't live very long; blood cells are only seven days, muscle cells are a year or two or three, I don't know, I haven't looked up all this stuff. But the point is that the cells come and go and what persists is all of the extracellular matrix that these cells have made: your tendons, the bones, the skin, all sorts of stuff that is not living, that was made by the cells and then thereby organized the behavior of the newer, younger cells. So we're not a collection of cells. We're more a stigmergy structure, more a termite mound, more this structure that's inhabited by all sorts of cells and the organization of them takes place largely within the stigmergy structure. And that has to be the way we think about designed or controllable multicellular computing systems.
Jon: And so to the extent that we do think about things that way, what does it lead us to?
Steve: The thing that I have used as an organizing principle in thinking about the web is to say that the cells or the sort of emerging organisms that are coming out of this soup of gazillions of computers talking to each other are defined by the stigmergy structures, not the computers. So if you want to figure out what's going on in the web, go out and look for stigmergy structures. So Flickr, for instance, created a whole new structure of tags and photos and that, by virtue of creating that stigmergy structure and then of course enticing enough people to participate, you have organized a whole new kind of thing, of organism. We don't know where it's going to go, because, it's only what, a couple years old? And all sorts of new ways to use that are coming into people's minds. But the point is, so, look for the stigmergy structures, not the individual behaviors of machines.
Jon: So I guess one question is, is what you call a stigmergy structure something which only emerges, or rather something which can be designed? Obviously, or I would say arguably in the case of Flickr, it was designed. The exception handling is one of the ways that I like to talk about it. That at the end of the day, the exception handling isn't a script that unwinds a transaction, it's somebody with some domain expertise that is not probably in our lifetimes ever going to be captured formally.
Steve: Yes, it was designed in the sense that all databases are designed, but the structure, the behavior that emerged around it, I would argue, probably was not exactly designed. They had a notion that they wanted a whole community to form, but they didn't have a notion of what it would do.
Jon: Right. It was designed, though, with enough of the foundations and the necessary flexibility, so that a range of things could emerge, and that kind of gets to a question that's pretty interesting to me, around web services. Which is, this might all sound pretty far-fetched, to a hard-nosed enterprise architect who's trying to sort out his relationships with WSDL business partners.
Steve: Yes. It gets to UDDI eventually.
Jon: Right, but you know, one thing I've always been pretty clear about is that, assuming that we solve those kinds of basic interactions, and have a vocabulary of objects, if you will, that we can exchange, and there's tons of work to be done there, but I don't really think that that's in itself kind of the end game. Because those transactions need to be embedded in a context, and that context is, in a lot of ways, created by the participants in the processes, as much as it is designed by the implementors of the systems that run the processes. And so the burden is then on the designers of those systems, not to presume that they can understand all of the context that's going to be created by the participants, but to make available the means by which those participants can collectively figure out for themselves what it is that they need to persist into the environment, if you will. To build the context that guides the less mechanical aspects of the web service transactions, right, the exception handling is one of the ways that I like to talk about it, right. That at the end of the day, the exception handling isn't a script that unwinds a transaction, it's somebody with some domain expertise that is not probably in our lifetimes ever going to be captured formally.
Steve: Yes, probably not. I like the notion of exception handling, because that has always been the thorn in the side of what was otherwise thought of as neatly architected and designed systems, Smalltalk, for example, but many others, Java, for instance. You have this nice flow of control and process that is designed and then you start putting on the exception stuff and you realize that all of the various paths have gotten out of control, in effect. Once you have all sorts of stack unwinding and exception handling, you no longer can quite tell what's going on in the system, and in web services, that's going to be the same thing, probably, in spades. So you have the main flow, which your WSDL can define relatively neatly, and then you have the exception flows, where suddenly you realize you don't know how it works. And so that is a problem in web services, and it probably will grow.
Jon: From my perspective, the way to think about attacking that problem is to observe that there are human beings, there are domain experts, who can't articulate what they know, but who can act on what they know.
Steve: Right. So you can make a web service with that human as one of the services, in effect. And some web service systems have that, where one of the nodes is really a human, interfacing through whatever WSDL is defined as how you talk to that human. That solves some problems.
Jon: This might be stretching it a little bit, but from a biological perspective, I think in terms of white blood cells. You get this kind of swarming behavior, ideally. When something goes wrong and a bunch of white blood cells are alerted to the fact that something has gone wrong, they converge on the site and they try to do something about it. That's very much what we would like to have happen in business processes.
Steve: Right.
Jon: And to the extent that that is the scenario that we envision, to me it seems that the problems are what kinds of messages need to be circulating in the system, what kind of notifications, what sorts of filtering, what sorts of awareness propagation mechanisms are going on in the biological system that allow this convergence to happen in a really natural way.
Steve: And that brings me to the fourth principle, incidentally, although it's not perfectly congruent with what you just said, it's closely related. And that is that multicellular systems, real multicellular organisms, have this thing called programmed cell death, or apoptosis, although apoptosis is odd because in Greek it would be apotosis, but the biologists mostly seem to pronounce the "t". So, anyway, it's a - p -o-, now I can't remember how to spell it!
Jon: Cellular suicide.
Steve: Thank you, cellular suicide. Which is a nicely formed messaging protocol in which every cell in a multicellular, let's just talk about humans, every human cell in the organism (and the reason I say that is because ten [ed: actually 90!] percent of our cells are actually bacterial cells, which most people don't know. Anyway, they don't quite participate in this, or at least in the same way) but all of the human cells sit on a knife edge between functioning normally and killing themselves. And that knife edge is tipped by two systems of messages, one says you're OK, you're cool (it's the I'm OK, you're OK messaging system in the body), which when everything is right in the body the cells are told you're great, don't kill yourselves, and in many cases all that has to happen is for something to change so that they don't receive those messages, and they say whoops! Something's wrong, I'd better die. The classic case is attachment. Most of the cells in the body, not in the blood, but in the harder structures of the body, are attached to the extracellular matrix. Their messaging system, their cell suicide messaging system, is such that if they get detached one way or another they cease to get those messages, and they immediately kill themselves. So, that's one reason that cancer does not proliferate until late in the disease, when the cancer cells have mutated to the point where they have disabled the cell suicide. Then they can float free in the blood and metastasize and create new tumors elsewhere in the body. But in the early stages, if they get detached, they kill themselves.
Jon: What's an example of a cell getting detached?
Steve: Well, wounds are the classic case. So when you cut yourself all sorts of cells get knocked loose and would be floating around the body where they aren't supposed to be, so they just kill themselves.
Jon: OK.
Steve: In the lab is where you find this the most. When you try to grow skin cells or multicellular organism cells in cell culture, they don't grow, because they're not attached properly, and so they all kill themselves.
Jon: So what would be the useful equivalent of this mechanism in the computing realm?
Steve: I don't have good ideas on that. Because, you have to have evolved this whole mutuality system of cells telling each other you're OK. And trying to figure out how to create it out of whole cloth is difficult. But consider, in a corporate IT infrastructure, where the boxes are supposed to be connected to the corporate network, and that as long as they are connected, and you have heartbeat messages coming out, once a second, you're OK, you're OK, everything's fine, and then you take one of those boxes and detach it from the network, well then the corporate security people are often freaked about that. Because what happened to that, let's say the machine was stolen, what happens to all that proprietary information on that box? And the way that we've tried to deal with that is with passwords, and all sorts of not very effective schemes. So I propose that the box itself, if it was designed, and if it was detached from the network, it would just self-destruct. [laughing] Not in hardware, but in software.
Jon: Or perhaps just become temporarily [laughing] locked up -
Steve: Temporarily locked [laughing] so that nobody could do anything with it. And you'd have to reattach it in some presumably elaborate ritual, that involves passwords or whatever to make sure you are doing the right thing, and then it comes back alive.
Jon: So all this is under the rubric of complexity, or managing complexity?
Steve: Yes, that's the theme that underlies a lot of what I wrote. The reason being that I've been fascinated by complexity theory and emergent phenomena and all of that for the last fifteen years, so it fits in. And the other reason being that these systems evolve to become more and more complex all the time, both biological and computing, so you'd better understand that.
Jon: One of the things that we discussed in email is that it's quite difficult for human minds to encompass many levels of abstraction. And it may be impossible for us to do that.
Steve: I argue that it is. It's impossible for us to manage more than three levels of abstraction at one time. Now we can manage lots of levels of abstraction, it's just that we can't think about them together. For instance you may know - I've been in computing for a long time so I used to wire wrap chips together to make drivers. So I understand how it works at the bit or actually wire signal level, I know how machine language works, I've written lots of assembly, all the way up to Smalltalk, I can think about any one of those, but when you are trying to do serious designer debugging, you're thinking of multiple things together trying to figure out where the interaction is going wrong, at that point you are trying to think about them at the same time. It's hard to do more than the central level you're looking at plus one level up and one level down.
Jon: It's really hard, and it's not just hard because it's mentally difficult to be aware of multiple levels at the same time, but also because there is this psychological problem: you need to believe in something! I can't question every assumption, up and down the stack, or I'll just go crazy, I have to think that there is some solid ground.
Steve: But you can get to solid ground at one level, and you think about it (I'm thinking about debugging more than just software, this is a system) at one level, and you're willing to grant that the stuff below it's OK, and maybe even the stuff above it, for a while and you get nowhere, I at least at some point switch and say, OK that level's not where the problem is, so I'll move to a different level and think about that one for a while. Now I'm assuming that the other levels are sort of stable and OK.
Jon: Right.
Steve: And that's difficult.
Jon: It is indeed. So part of what would come out of this, is in your view that we are never going to have this global ability to understand things, and that we will be creating systems that will be creating emergent behaviors that we can't understand, therefore the reason for studying these principles and thinking about how we should apply them is that that's really the only way we can do stuff. To use what we think are the right principles, accepting the fact that what gets created on top of them is going to be in some ways incomprehensible to us even in principle.
Steve: Yes. Well it's twofold. Yes, just our abilities are insufficient, and the other part is that when another level emerges -- so you have the level of individual computers that have web browsers and HTTP and IP stacks and all this other crap, and then you put a whole bunch of them together, and they start interacting, that the cause and effect of what goes in between them if you change the IP stack, well that's all fixed now, but suppose the stuff is changing because we need new IP 6 or web 2.0, there are changes coming down the pipe, that when we change those things, that the cause and effect link between that and what the next level up is going to do isn't just too difficult for us to think about, it actually emerges because of positive feedback loops. So it's literally unpredictable. It's not a matter of can we mentally process it, it's that it hasn't even happened yet, and as conventions form that then feed back positively on the IP stack, on people, etc., a whole new level emerges that is not predictable. Once it's emerged you might be able to understand it, but you can't say in advance what's going to emerge out of it. So there is no way we're going to understand all of the systems.
Jon: Well, given that we do hope to do the right thing and avoid doing the wrong thing, what are the strategies then, how do we move in the direction of at least figuring out what the strategies should be?
Steve: Well, I don't believe that I know the answer to that. What I'm proposing in this paper is that you want to try to make explicit and think about the four principles. Have you specialized the various devices properly, or turn it around, have you left general purpose behavior at a level that just shouldn't have it because it is going to cause you trouble, in other words are you not sufficiently specialized; have you made sure that your messaging is polymorphic, meaning that the semantics are determined by the receiver.
Jon: I want to replay that first bit because I think that's interesting. You say that a possible guiding principle here is to avoid too much general purpose capability?
Steve: Yes.
Jon: Because it's dangerous.
Steve: Because it will allow many more kinds of unexpected emergent behavior. The more general the individuals are, the more difficult it is to figure out what putting a whole bunch of them together is going to do.
Jon: That's an extremely interesting and perhaps controversial thing because, how do you know what to subtract? Or what the consequences will be if you subtract the wrong thing.
Steve: Absolutely. You've hit exactly the right point. Subtractive specialization is infinitely more difficult because you never know who's relying on something. Word, is a classic example, Microsoft was pilloried ten years or so ago for feature bloat in Word. Even Microsoft agreed at one point it would be nice if it was simpler because it was too hard for everyone to learn. But then they tried to ask people what they could remove without causing trouble, and the answer was, everyone had a different set of behavior that they needed, and basically there was nothing that they could take out that wouldn't cause serious trouble for some part of the base. But that's the problem with subtractive specialization. What we need is additive specialization, in that we start some new system, say for example, the new hundred dollar laptop scheme that MIT is doing; so start it very simple and add what's necessary, don't start it general purpose and try to later subtract it. Cell phones is another classic case although that may be already too far gone.
Jon: Although I would say that the hundred dollar computer is a relatively general purpose device. I mean it has presumably a Linux OS...
Steve: It has a part of a Linux OS.
Jon: It can run a broad range of applications...
Steve: Well the CPU is fundamentally general purpose, so yes in that sense. But in the way you set up the operating system, they way you set up the loading of new software, determines how general purpose it can be. If the philosophy is the same as that we currently have for PCs in general, is that they are nice mechanisms for sticking anything you want on them and furthermore, there's broadcast mechanisms for getting them out there all over the place, then yes, it will become very general purpose very quickly.
Jon: Mmm hmmm.
Steve: But the hardware is not very general purpose. I don't know what's going to be on that box, but it's not going to have oodles of USB ports, and microphones and speakers, and high powered video graphics generators, and all that kind of stuff. So just because of the hundred dollar price point, the thing is going to be more special purpose than a regular PC.
Jon: OK. OK.
Steve: Whether that's enough special purpose or not I don't know.
Jon: I see what you mean though, it's very interesting.
Steve: The main point is that I agree with you. Trying to make specialization by subtractive behavior runs into the marketplace, it's not going to work.
Jon: Or it's not going to work in the first world. [laughing]
Steve: Yes. So, imagine that UPS had all of their people with a special purpose device already. I don't know how special purpose they are, I'd have to look into that. Maybe they have all sorts of general purpose graphics we don't know about. But they've started with an ecology of thousands of people with special purpose devices and you can grow that by carefully adding behavior to support the multicellular UPS system. Like a GPS system in every one of their handheld things that you sign when the come to your door, they could add a GPS unit into that, so that they'd always know where everything is. They could slowly add behavior to form a multicellular organism that is specialized for UPS. And never go through having every one of their drivers having a Windows box that is full of viruses and crashes all of UPS.
Jon: I suppose so, but another take would be that if they had a kind of general purpose hardware which could be reprogrammed to do a variety of things which weren't originally anticipated, then they wouldn't have to rev their installed base. But this is now contradicting your fear of distributable code, right?
Steve: Which brings us to the question you had in the email which is about versioning, and how does that fit into all of this.
Jon: What I was wondering there is if there are any examples in the world of biology of versioning issues.
Steve: Yes, in the world of single celled biology. In the multicellular world, no.
Jon: So what's an example of versions in the single celled world?
Steve: When they pass a chunk of new DNA around. Which may do nothing, it may kill the other cells, or it may do something really cool, such as protect them or help them defend against antibiotics.
Jon: So when I accept new DNA, I become a new version of me if I'm one of these things.
Steve: Right. You become something new. In the single celled world this is fine because it's just Darwinian evolution, if you accept something that wasn't cool, you're dead. End of story. And the ones that accept something that turns out to be valuable end up proliferating take over the slime pool. Works great. Multicellular organisms, you get your full complement of DNA when the egg is fertilized, end of story, no versioning.
Jon: Right. And then the relevant domain of reprogramming is the cultural domain.
Steve: Yes, oh yes. Memetics and all of that is an entirely different world that is not, well it is Darwinian, but it's not in any way Mendelian. You know what I mean. Anyway, whole different world. That world by the way, has some emergent structures, even has some sorts of apoptosis, some sorts of suicide. Meaning that some meme structures, some belief systems, some religious whatevers, that say, lead to suicide bombers? That is a memetic suicide mechanism.
Jon: Mmm hmm. What are the next steps for you? Where do you want to go with this?
Steve: We need to get a conversation going with lots of people that can grow. Because the implications of these things are huge, but who knows what they are yet? I can't write a prescription that says, just do this and multicellular IT systems will be fine. I believe that these four principles will be central, but there is going to have to be some practical bringing it down to step by step before it's going to take off.