Author Archive

December 22, 2006

Smart people can rationalize anything

One of the things we were able to do at Electric Communities was to attract one of the highest density collections of scary-smart people I’ve ever seen gathered in one place before. There are a lot of nice things about working with smart people. For one thing, they’re not stupid. Working with stupid people just sucks. Smart people are good if you need to do a lot of really hard things, and we did a lot of really hard things. But it’s not all upside. For one thing, smart people tend to systematically overestimate the value of being smart. In fact, it is really valuable, but they still tend to weight it too heavily compared to other virtues you might also value, such as consistency, focus, attentiveness to the emotional needs of your customers, and so on. One of the problems with really smart people is that they can talk themselves into anything. And often they can talk you into it with them. And if you’re smart yourself, you can talk them into stuff. The tendency to drift and lack of focus can be really extreme unless you have a few slower people in the group to act as a kind of intellectual ballast.

Why do less when you can do more?

Smart people can invent solutions to problems you don’t actually have yet. The problem is, it’s easy to think of problems you don’t have yet. Stopping to solve them all now is a recipe for paralysis. Furthermore, while it’s easy to think of all kinds of potential future problems, it’s much harder to forsee which of those you will actually have, much less all the ones that you are going to have that you didn’t anticipate. People who are less smart manage to avoid pouring resources into unnecessarily solving future problems because they aren’t able to figure out how to solve those problems anyway. So they just ignore them and hope they don’t actually come up, which in a lot of cases turns out to be the way to have bet.

Programming sage Donald Knuth taught us that “premature optimization is the root of all evil.” It turns out that this doesn’t just apply to coding.

You can’t sell someone the solution before they’ve bought the problem

Smart people can invent solutions to problems folks actually do have but don’t know it yet. These solutions are usually doomed. This ties in with the whole You Can’t Tell People Anything principle. It is nearly impossible to solve a problem for someone if they don’t believe they have the problem, even if they really, really do.

For example, one of the deep flaws in many distributed object schemes, such as the CORBA standard, is that they make no effective provision for distributed garbage collection. This is a major pain, because if storage management is annoying to get right in a non-distributed system, it can be brutally so in a distributed system. Java’s Remote Method Invocation standard is somewhat better in that it does do DGC, but it still can’t cope with unreferenced distributed cycles. One of our wiz kids, Arturo Bejar, devised for us a truly elegant DGC algorithm, which is not only efficient but gracefully handles distributed cycles. (To my eternal shame we patented it.) Since to work well in Java it really wanted to be in bed with the Java Virtual Machine, we tried to sell it to JavaSoft, who were literally next door to us in Cupertino (actually, we tried to give it to JavaSoft), but they weren’t interested. They hadn’t bought the problem yet. So a small piece of great technology that could make the world a slightly better place sits on the shelf.

Generalitas gratia generalitatis

(For those of you who, unlike me, lack a co-worker who spent 7 years studying Latin, whom you can bug for stuff like this, that’s “Generality for Generality’s Sake”.)

Smart people love to think about the general case scenario.

For example, at Electric Communities we ended up making a big investment in developing an orthogonal persistence mechanism for our object infrastructure. For those of you who are unfamiliar with it, orthogonal persistence is one of the ultimate examples of highly generalized technical coolness. Basically, the idea is that you abstract away the file system (or any other persistent storage, like a database) by keeping everything in memory and then playing tricks with the virtual memory system to make processes immortal. The example we were inspired by was KeyKOS, a highly reliable OS for IBM mainframes that was developed by some friends of ours in the 1980s, in which you could literally pull the power plug from the wall, and, after plugging it back in, be rebooted and running again — including transparently resuming all the running processes that were killed when you cut the power — in about 8 seconds (this was actually one of their trade show demos). You gotta admit, that’s pretty cool. Some commercial installations of KeyKOS have had processes with running times measured in years, surviving not only power failures and hardware malfunctions, but in some cases actual replacement of the underlying hardware with newer generations of equipment.

Orthogonal persistence was attractive to us not just because of the reliability enhancements that it promised, but because it would free programmers from having to worry about how to make their objects persistent, since it abstracted away all the serialization and deserialization of object state and associated design questions. Anything that made programming objects simpler seemed like a big win. And so we built such a system for our object framework, and it worked. It wasn’t quite as awesome as KeyKOS, but it was still pretty awesome.

One of my favorite catch phrases is, “The difference between theory and practice is that, in theory, there is no difference, but, in practice, there is.” Orthogonal persistence was a great idea — in theory. Of course it cost months and months of development time, and it introduced a number of subtle new problems, any one of which would have a made a good PhD dissertation topic. If you are trying to produce a commercial product in a timely and cost efficient way, it is not good to have somebody’s PhD research on your critical path. For example, it turns out that for most kinds of objects, the amount of state you actually need to save persistently is a small fraction of the full run-time state of the object. But in an orthogonal scheme you save it all, indiscriminately. The problem is not so much that it’s bulky, though it is, but that the volume of semantic meaning that you are now committed to maintain in near-perpetuity is vastly increased. That turns out to be very expensive. The problem of schema migration as new versions of objects were developed (due to bug fixes or feature enhancements) proved effectively intractable. Ultimately we fell back on a scheme that compelled programmers to be much more deliberate about what state was checkpointed, and when. That proved more practical, but in the meanwhile we lost literally years of development resources to the blind alley. Less sophisticated developers would not have gone down this blind alley because they wouldn’t have a clue that such a thing was even possible, let alone be able to figure out how to do it. They would have been saved by their own simplicity.

Keep in mind that all of the foregoing is not an argument against being smart. Rather, it’s a recognition that human rationality is bounded, and even really, really smart people must necessarily fall far short of mastering the complexities of a lot of the things we do, as engineers, as business people, and as ordinary human beings. What works the kinks out of a thing is often just the passage of time, as the shortcomings and subtleties gradually emerge from practice. Because stupid people work more slowly, they get the benefit of time for free, whereas smart people have to work at it.

November 6, 2006

A Contrarian View of Identity — Part 2: Why is this confusing?

This is Part 2 of a multi-part essay on identity. Part 1 can be found here. Part 1 ended with a promise that Part 2 would be up soon, but, as John Lennon once said, life is what happens to you while you’re busy making other plans. But at long last here we are; enjoy.

Part 1 talked, in broad strokes, about the kinds of things that identity gets used for and why, but ended with the assertion that identity is being made to carry a heavier load than it can really support given the character and scope of the Internet. Here I’m going to speculate about why discussion of this seems to generate so much confusion.

One area of confusion is illustrated by a long-standing split among philosophers over the fundamental nature of what an identifier is. They’ve been chewing on the whole question of identity and naming for a long time. In particular, Bertrand Russell and his circle proposed that a name should be regarded as a form of “compact description”, whereas a line of thought promoted by Saul Kripke asserts that names should instead be viewed as “rigid designators”.

The “compact description” point of view should be one that is familiar from the physical world. For example, if you are pulled over for speeding and the police check your driver’s license, they consider whether you resemble the person whose photograph and description are on it. The “rigid designator” perspective is more familiar in the world of computer science, where we use such designators all the time in the form of memory pointers, DNS names, email addresses, URLs, etc.

Without delving into the philosophy-of-language arcana surrounding this debate, you can at least note that these are profoundly different perspectives. While I personally lean towards the view that the “rigid designator” perspective is more fundamental, this is basically a pragmatic position arrived at from my work with object capability systems and the E programming language. In the present discussion you don’t need to have a position yourself on whether either of these positions is right or wrong in some deep, essential sense (or if that’s even a meaningful question). All you need to recognize is that people who come at the identity issue from these different directions may have very different notions about what to do.

Another wellspring of confusion is that different people mean different things when they speak of “identity”. Moreover, many of them seem unaware of or indifferent to the fact that they are talking about different things. While I generally think that the Parable of The Blind Men and The Elephant is way overused, in this case I think it’s a wildly appropriate metaphor. Identity is a complicated concept with a number of different facets. Depending on which facets you focus your attention on, you end up believing different things.

Let’s look at the relationship between two entities, call them Alice and Bob, interacting over the Net. I diagram it like this:

We call them Alice and Bob simply because anthropomorphizing these situations makes them easier to think and talk about. We don’t actually care whether Alice and Bob are people or computers or processes running on computers or websites or whatever. Nor do Alice and Bob both have to be the same kind of thing. All that we care about are that each is some kind of discrete entity with some sense of itself as distinct from other entities out there.

When Alice interacts with Bob, there are (at least) four different distinct acts that are involved, each involving something that somebody somewhere calls “identity”. (1) Bob presents some information about himself, in essence saying “this is me”. (2) Alice, using this information, recognizes Bob, that is, associates the entity she is interacting with with some other information she already knows (remember that we said in Part 1 that relationships are all about repeated interactions over time). (3) Alice, to take action, needs to make reference to Bob. She designates Bob with some information that says, in essence, “that is you”. (4) Bob, based on this information, plus other information he already knows, accepts that Alice is referring to him and provides access to information or services.

At various times, various people have referred to the bundle of information used in one or another of these acts as Bob’s “identity”. However, there are four, potentially different, bundles of bits involved. These bundles can be considered singly or in combination. Depending on which of these bundles your view of things takes into account or not, there are fifteen different combinations that one could plausibly label “identity”. Furthermore, you get different models depending on whether or not you think two or more of these bundles are actually the same bits — the number of possibilities explodes to something like 50 (assuming I’ve done my arithmetic correctly), before you even begin talking about what the rules are. Absent awareness of this multiplicity, it is not surprising that confusion should result.

Observe too that this picture is asymmetrical. Most real interactions between parties will also involve the mirror counterpart of this picture, where Alice does the presenting and accepting and Bob does the recognizing and designating. Note that though the two directions are logical duals, the mechanisms involved in each direction might be radically different. For example, when I interact with my bank’s website, I present a username and password, while the bank presents text, forms, and graphics on a web page.

Those of you of a more technical bent are cautioned to keep in mind that I’m describing an abstract model, not a protocol. In informal discussions of this diagram with techie friends, I’ve noticed a tendency for people to latch onto the details of the handshaking between the parties, when that’s not really the point here.

This model now gives us a way to get a handle on some of the muddles and talking at cross purposes that people have gotten into.

Consider the many people making claims of the flavor, “you own your own identity” (or should own, or should control, or some similar variant of this meme). If you are focused on presentation, this makes a degree of sense, as you are thinking about the question, “what information is Bob revealing to Alice?” If you are concerned with Bob’s privacy (as Bob probably is, let alone what privacy advocates are worried about), this question seems pretty important. In particular, if you adopt the “compact description” stance on names, it seems like this identity thing could be probing pretty deeply into Bob’s private business. On the other hand, if you are focused on recognition, the “you own your own identity” idea can seem both muddled and outrageous. Recognition involves combining the information that was presented with information that you already know; indeed, in the absence of that pre-existing knowledge, the information presented may well be just so much useless noise. From this perspective, a claim that Bob owns his own identity looks a lot like a claim that Bob owns part of the contents of Alice’s mind. It should not come as a big surprise if Alice takes issue with this. Note that this is distinct from a political position which positively asserts that there should be (or believes that there could be) some legal or moral restrictions on what Alice is allowed to know or remember about Bob; there’s an interesting debate there but also a distraction from what I’m talking about.

Note that although the model is explained above in terms of just Alice and Bob, the most interesting questions only emerge in a world where there are more than two actors — if your world only contains one entity besides you, the whole question of the other’s identity is rather moot.

Let’s introduce Carol, a third party, into the picture. Setting aside for a moment discussion of what the identity relationship between Alice and Carol is, consider just the issue of how Bob’s identity is handled by the various parties. Recall that there are four bundles of information in the identity relationship of Bob to Alice:

  • the information that Bob presents to Alice
  • the information that Alice holds, enabling her recognize Bob from his presentation
  • the information that Alice uses to designate Bob
  • the information that Bob holds, enabling him to accept Alice’s designation

What is the scope of this information? Is the information that Bob presents to Alice meaningful only in the context of their particular two-way relationship, or is it meaningful in some broader context that might include other parties? In particular, is the information Bob presents to Alice unique to Alice, or might Bob present himself differently to Carol? If Carol already has a relationship to Bob, do Alice and Carol have the means to know (or to discover) that they are talking about the same Bob? More generally, which, if any, of the above listed four pieces of information does Carol see? Where does she get this information from? From Bob or from Alice or from some third (er, fourth) party?

Similarly, is the information Bob presents to Alice unique to Bob, or might some other entity besides Bob present the same information to her? In the latter case, is she really recognizing Bob or just some abstract Bob-like entity?

Each of these questions, and countless others which I didn’t explicitly raise or perhaps am not even overtly aware of, defines a dimension of the design space for an identity framework. The explosion of possibilities is very large and quite probably beyond the scope of exhaustive, systematic analysis. Instead, it seems more useful to pay attention to the purposes to which an identity system is being put. Any particular design can’t help but embed biases about the ways in which the designers intend it to be used (in and of itself, this is only a problem if the design has pretensions to universality).

I’m not prepared to go into all of these questions here. That’s probably the work of a lifetime in any event. However, there is one very important consideration that I’d like to highlight, which hinges on the distinction between the information that Bob presents to Alice and the information with which Alice designates Bob.

The presentation information seems naturally to fall into the “compact description” camp, whereas the designation information seems to just as naturally fall into the “rigid designator” camp. Indeed, the very language that I’ve adopted to label these pieces contains a bias towards these interpretations, and this is not an accident.

From Bob’s perspective, the information that designates him is far more dangerous than the information he presents. This is because a designator for Bob is the means by which an outside party acts upon Bob. Such action can range from pointing him out to other people in a crowd to sending him email to charging his credit card, depending on the context. Any of these actions might be beneficial or harmful to him, again depending on context, but Bob is fundamentally limited in his ability to control them. Presentation, by contrast, is more clearly under Bob’s control, and the risk posed by presentation information is closely related to the degree to which that information can be reverse engineered into designation information.

Much of the risk entailed by these interactions stems from the fact that in the real world it is rarely Bob himself who does the presenting and accepting; rather it tends to be various intermediaries to whom Bob has delegated these tasks in different contexts. These intermediaries might be technological (such as Bob’s web browser) or institutional (such as Bob’s bank) or an amalgam (such as Bob’s bank’s ATM). Such intermediaries tend to be severely limited in the degree to which they are able to exercise the same discretion Bob would in accepting a designator on Bob’s behalf, partially because they tend to be impersonal, “one size fits all” systems, but mainly because they cannot know everything Bob knows. Analysis is complicated by the fact that they may be able to compensate for some of these limitations by knowing things that Bob can’t. The ubiquitous presence of these intermediaries is a major difference between our modern, online world and the evolutionary environment in which our instincts for these things emerged.

Note that designation is generally associated with specific action. That is, there is usually some particular intent that Alice has in mind when designating Bob, and some specific behavior that will be elicited when Bob accepts the designator. This favors the “rigid designator” perspective: highly specific, with little tolerance nor use for ambiguity. In particular, different designators might be applied to different uses. In contrast, presentation may be open-ended. When Bob presents to Alice, he may have no idea of the use to which she will put this information. The information may, in some contexts, be quite general and possibly entirely ambiguous. This favors the “compact description” perspective.

All of the above leads to the following design prescription: these two bundles of information ought not to be conflated. In particular, Bob most likely will want to exercise much greater control over designation information than over presentation information. In any event, the contexts which these will be used will be different, hence the two should be separate. Furthermore, designation should not be derivable from presentation (derivation in the other direction may or may not be problematic, depending on the use case).

In Part 3 (about whose timing I now know better than to make any prediction), I’ll take a look at some of the more popular identity schemes now being floated, and use this model to hold them up to some critical scrutiny.

June 30, 2006

Things You Find While Cleaning Your Office

I was going through a bunch of old papers trying to find some old crap I could throw away to make room for all the new crap I keep accumulating, and I came across a document I had written for Xanadu back in 1984. This was a tome documenting the various Xanadu data structures. It was written as part of a deal we were doing to try to get some funding from the System Development Foundation. This was back in the day when we were still stupid about intellectual property and regarded all our secret knowledge as highly proprietary magic to be guarded jealously.

Our lawyer wrote a paragraph for the cover, indicating to potential readers the proprietary nature of what they were about see and reminding them of the non-disclosure agreement that they were bound by:

This document describes data structures, designs and concepts which are the proprietary intellectual property of Xanadu Operating Company, Inc. The contents of this document are not for distribution or release in whole or in part to any other party without the express permission of Xanadu Operating Company, Inc. All portions of this document are to be considered trade secrets of Xanadu Operating Company, Inc. including the fact that some previously published data structures may fall into the classification of “enfilades”.

All pretty standard stuff (except possibly for the last sentence, which I’ll admit is a bit weird). However, being the snide young whippersnappers that we were at the time, we felt that though this covered the legal bases it didn’t quite communicate the significance of the message we were trying to convey. So I added the following beneath it:

WARNING!

He who transgresses against the propriety of the Information contained herein shall be Cursed! Woe unto all who reveal the Secrets contained herein for they shall be Hunted unto the Ends of the Universe. They shall be afflicted unto the Tenth Generation with Lawyers. Their Corporate Bodies shall be Broken and cast into the Pit. Their Corporate Veil shall be pierced, and Liability shall attach to the Malefactors in personem. They shall suffer Ulcers and Migraines and Agonies Unimagined. Yea, Verily, for such shall come to pass against all who would Dare to Test the Powers of Xanadu unto their Doom.

Just thought it would be good to get that on the record before I lost the piece of paper again.

Charlie Smith, the head of the System Development Foundation, did not object to this. However, Jeff Ullman, one of his technical reviewers (and chairman of the Stanford Computer Science Department at the time), was entirely put off. He said, “I’m not going to read this. It’s got a curse on it!”

March 26, 2006

A Contrarian View of Identity — Part 1: What are we talking about?

I was approached a few weeks ago to begin thinking about identity, the first time I’ve had the chance to get seriously into this subject for several years. In the time since my last big confrontation with these issues (at Communities.com circa 1999-2000, when we were worrying about registration models for The Palace) there has been a lot of ferment in this area, especially with problems such as phishing and identity theft being much in the news.

As I survey the current state of the field, it’s clear there are now enormous hordes of people working on identity related problems. Indeed, it seems to have become an entire industry unto itself. Although there are the usual tidal waves of brain damaged dross and fraudulent nonsense that inevitably turn up when a field becomes hot, there also seems to be some quite good work that’s been done by some pretty smart people. Nevertheless, I’m finding much of even the good work very unsatisfying, and now feel challenged to try to articulate why.

I think this can be summed up in a conversation I recently had with a coworker who asked for my thoughts on this, and my immediate, instinctive reply was, “Identity is a bad idea; don’t do it.” But unless you’re already part of the tiny community of folks who I’ve been kicking these ideas around with for a couple of decades, that’s probably far too glib and elliptical a quip to be helpful.

The problem with identity is not that it’s actually a bad idea per se, but that it’s been made to carry far more freight than it can handle. The problem is that the question, “Who are you?”, has come to be a proxy for a number of more difficult questions that are not really related to identity at all. When interacting with somebody else, the questions you are typically trying to answer are really these:

  • Should I give this person the information they are asking for?
  • Should I take the action this person is asking of me? If not, what should I do instead?

and the counterparts to these:

  • Can I rely on the information this person is giving me?
  • Will this person behave the way I want or expect in response to my request? If not, what will they do instead?

Confronted with these questions, one should wonder why the answer to “Who are you?” should be of any help whatsoever. The answer to that is fairly complicated, which is why we get into so much trouble when we start talking about identity.

All of these questions are really about behavior prediction: what will this person do? To interact successfully with someone, you need to be able to make such predictions fairly reliably. We have a number of strategies for dealing with this knowledge problem. Principal among these are modeling, incentives, and scope reduction. Part of the complexity of the problem arises because these strategies intertwine.

Modeling is the most basic predictive strategy. You use information about the entity in question to try to construct a simulacrum from which predictive conclusions may be drawn. This can be as simple as asking, “what would I do if I were them?”, or as complicated as the kinds of elaborate statistical analyses that banks and credit bureaus perform. Modeling is based on the theory that people’s behavior tends to be purposeful rather than random, and that similar people tend to behave in similar ways in similar circumstances.

Incentives are about channeling a person’s behavior along lines that enhance predictability and improve the odds of a desirable outcome. Incentives rely on the theory that people adapt their behavior in response to what they perceive the consequences of that behavior are likely to be. By altering the consequences, the behavior can also be altered. This too presumes behavior generally to be purposeful rather than random, but seeks to gain predictability by shaping the behavior rather than by simulating it.

Scope reduction involves structuring the situation to constrain the possible variations in behavior that are of concern. The basic idea here is that the more things you can arrange to not care about, the less complicated your analysis needs to be and thus the easier prediction becomes. For example, a merchant who requires cash payment in advance avoids having to consider whether or not someone is a reasonable credit risk. The merchant still has to worry about other aspects of the person’s behavior (Are they shoplifters? Is their cash counterfeit? Will they return the merchandise later and demand a refund?), but the overall burden of prediction is reduced.

In pursuing these strategies, the human species has evolved a variety of tools. Key among these are reputation, accountability, and relationships.

Reputation enters into consideration because, mutual fund legal disclaimers notwithstanding, past behavior is frequently a fairly good predictor of future behavior. There is a large literature in economics and sociology demonstrating that iterated interactions are fundamentally different from one-time interactions, and that expectation of future interaction (or lack thereof) profoundly effects people’s behavior. Identity is the key that allows you connect the party you are interacting with now to their behavioral history. In particular, you may able to connect them to the history of their behavior towards parties other than you. Reputation is thus both a modeling tool (grist for the analytical mill, after all) and an incentive mechanism.

Accountability enters into consideration because the prospect that you may be able to initiate future, possibly out-of-band, possibility involuntary interactions with someone also influences their behavior. If you can sue somebody, or call the cops, or recommend them for a bonus payment, you change the incentive landscape they operate in. Identity is the key that enables you to target someone for action after the fact. In addition to the incentive effects, means of accountability introduce the possibility of actually altering the outcome later. This is a form of scope reduction, in that certain types of undesired behavior no longer need to considered because they can be mitigated or even undone. Note also that the incentives run in both directions: given possible recourse, someone may choose to interact with you when they might not otherwise have done so, even if you know that your own intentions were entirely honorable.

Note that reputation and accountability are connected. The difference between them relates to time: reputation is retrospective, whereas accountability is prospective. One mechanism of accountability is action or communication that effects someone’s reputation.

Relationships enter into consideration because they add structure to the interactions between the related parties. A relationship is basically a series of interactions over time, conducted according to some established set of mutual expectations. This is an aid to modeling (since the relationship provides a behavioral schema to work from), an incentive technique (since the relationship itself has value), and a scope limiting mechanism (since the relationship defines and thus constrains the domain of interaction). What makes a relationship possible is the ability to recognize someone and associate them with that relationship; identity is intimately bound up in this because it is the basis of such recognition.

All of this is fairly intuitive because this is how our brains are wired. Humans spent 100,000 or more years evolving social interaction in small tribal groups, where reputation, accountability and relationships are all intimately tied to knowing who someone is.

But the extended order of society in which we live is not a small tribal group, and the Internet is not the veldt.

End of Part 1

In Part 2 (up soon) I will talk about how our intuitions involving identity break down in the face of the scale of global civilization and the technological affordances of the Internet. I’ll also talk about what I think we should do about it.

March 19, 2006

Resilience is better than anticipation

“In preparing for battle I have always found that plans are useless, but planning is indispensable.”
— Dwight D. Eisenhower

Paul Saffo, favorite futurist of every journalist on the tech beat, famously said, “Never mistake a clear view for a short distance”. An important corollary is: being able to see the destination doesn’t necessarily mean you can see the road that gets you there. One lesson I take from this is that trying to plot a detailed map of that road can be a big waste of time.

This tome represents half a million (1993) dollars of Grade A, USDA Choice, prime Vision, happily paid for by our friends at Fujitsu. This lays it all out, in loving detail. This is the document that sold the venture capitalists on funding Electric Communities’ transition from a three-guys-who-do-cyberspace consulting partnership to a full bore Silicon Valley startup company. We had a regular business plan too (albeit one that was a little vague in the “and this is where the money comes from” part; see It’s a business, stupid), but what the VCs were really buying into was this: the utopian dream. It was exhilarating, it was brilliant, it was some of the best work I’ve ever done.

It was doomed.

It was at once too detailed and too vague. This is the nature of big complicated plans: they have lots of details (that’s what makes them big and complicated) and they leave lots out (because, the world being the complex thing that it is, no matter how much detail you give, it’s never enough to completely describe everything relevant). Plus, the more details and complexities there are, the more opportunities you have to make mistakes. As the number of elements you are juggling grows large, the probability of significant errors approaches certainty. (One notable VC who declined to invest in Electric Communities told us, “This is one of those Save The World plans. We don’t do those; they never work.” I want him for an investor the next time I try to start a company.)

Big utopian plans are doomed by their very natures, because they are always wrong. Being the huge fan of F. A. Hayek that I am, I should have figured this one out a lot sooner. I no longer believe in big plans that try to comprehensively anticipate every requirement and every contingency. Instead, I believe in resilience. Resilience is better than anticipation (a formulation for which I need to credit my friend Virginia Postrel).

It is better to have a simple plan and be resilient in its execution.

By resilience, I mean the ability to quickly and inexpensively adapt to the inevitable changes in circumstance, unforseen events, and surprising discoveries that any significant undertaking is bound to encounter. Unless what you are doing is completely trivial, the awful truth is that you must do it in an environment that is filled with uncertainty.

Most people will acknowledge the value of being prepared for unexpected external contingencies like earthquakes or downturns in the market. Fewer will take into account the broader, more diffuse, but ultimately more important phenomenon which plagues most long-term projects, namely that the nature of the world shifts between the time you start and the time you plan to be done, so that a plan that might have been ideal when you started might be disastrous by the time you finish (Freeman Dyson has some interesting things to say about this in Infinite in All Directions). Very few indeed appreciate what I think is the biggest source of uncertainty, which is that you don’t really understand exactly what to do and how to do it until you are well on your way to having already done it. It is in the doing of a thing that you end up discovering that you need to do other things you hadn’t originally counted on or that you now need to do some things differently from how you’d originally intended. Indeed, you may discover that you’ve already done some things wrong that now need to be done over or just thrown away.

You might reasonably ask how I can possibly reconcile this extreme skepticism about the value of (or, indeed, the possibility of) planning with what I mainly do for a living, which is to develop large, complex software systems. These undertakings would seem to demand exactly the kind of comprehensive, large-scale planning that I’m criticizing here. Indeed, this is how the world of software engineering has usually approached things, and they have the long history of schedule overruns, budget blowouts, and general mayhem and misery to prove it. Accepting the limitations of human rationality with respect to planning and forecasting is merely bowing to reality.

My new religion, in the realms of project planning in general and software development in particular, is what I guess I’d call “hyperaggressive incrementalism”:

Do really small steps, as small as you can manage, and do a lot of them really, really fast.

Don’t do anything you don’t have to do, and don’t do anything that you don’t have an immediate need for. In particular, don’t invest a lot of time and effort trying to preserve compatibility with things that don’t exist yet.

Don’t try too hard to anticipate your detailed long term needs because you’ll almost certainly anticipate wrong anyway. But be prepared to react quickly to customer demands and other changes in the environment.

And since one of the dangers of taking an incremental approach is that you can easily drift off course before you notice, be prepared to make sweeping course corrections quickly, to refactor everything on a dime. This means that you need to implement things in a way that facilitates changing things without breaking them.

Don’t fix warts in the next rev, fix them now, especially all the annoying little problems that you always keep meaning to get around to but which never seem to make it to the top of your todo list. Those annoying little warts are like barnacles on a ship: individually they are too small to matter, but in aggregate their drag makes it very hard to steer and costs you a fortune in fuel.

Simple is better than complicated. General is better than specialized. But simple and specialized now is better than general and complicated some day.

With respect to software in particular, adopt development tools and processes that help you be resilient, like memory safe, strongly typed, garbage collected programming languages and simple, straight-ahead application frameworks (i.e., Java very good, J2EE very bad). I also favor rigorous engineering standards, ferociously enforced by obsessive compulsive code nazis. I sometimes consider it a minor character flaw that I’m not temperamentally suited to being a whip-cracking hardass. Every team should have one.

Writing things down is good, but big complicated specifications are of a piece with big utopian plans: too ponderous to be useful, usually wrong, and rapidly obsolescent.

In general, it is better to have a clear, simple statement of the goal and a good internal compass, than to have a big, thick document that nobody ever looks at. That good internal compass is key; it’s what distinguishes a top tier executive or developer from the second and third stringers. Unfortunately, the only way I’ve found to tell whether someone is good in this respect is to work with them for several months; that’s pretty expensive.

My bias at this point is to favor productivity over predictability. It’s OK to have a big goal, possibly even a really big, visionary, utopian goal, as long as it’s just a marker on the horizon that you set your compass by. Regardless of what plans you may have (or not), a productive process will reach the goal sooner. Though predictability is elusive, productivity, in contrast, is actually achievable.

December 12, 2005

The Meeting

Screw Leibniz; forget monads. I am convinced that the fundamental ontological construct of the universe is The Meeting. The Meeting is one. There is only one Meeting. The Meeting is all. The Meeting is like The Force™ — it fills all things and all the empty spaces between them. At different times, you may notice that The Meeting is in a different place than it was before, or that there are different people in The Meeting with you, or that, somehow, the topic of discussion has changed. Sometimes, you step out to go to the bathroom, or eat a meal, or make a phone call, but The Meeting is always there, waiting, and in the end you always return to it. The Meeting remains, timeless, endless, eternal. Though it has many different aspects, many different agendas, in the end, there is only The Meeting. The Meeting is all.

That’s all I have time for today. I gotta get back to The Meeting.

April 27, 2005

Chip's A Yahoo!

One of the odder side effects of working closely with somebody else for nearly 20 years, which you only discover by not working with them for a while, is that a small but important fraction of what you know ends up being actually stored in the other person’s brain. I encountered this strange phenomenon in early 2003, after our most recent startup, State Software, ignominiously cratered in the face of our principal investor’s feckless amateurism as a venture capitalist. Suddenly faced with the need to get real jobs to put food on the table, our heroes were forced to take separate paths. Randy (after some exciting adventures that, as Michael Flanders says, we’ll tell you all about some other time) landed at Yahoo!, and I wound up in my present job at Avistar. It was after settling into the new job that I experienced the curious and disconcerting sensation of not being able to access some of the stuff I knew I knew, as it was in a different head 15 miles or so to the south. (I’ll let Randy speak for himself as to whether he experienced any analog to this weirdness.)

Thus it is that I am thrilled to announce that after next week I shall put down my hammer, tweezers, astrolabe, and other code refactoring tools at Avistar and become instead a fellow Yahoo! alongside my long-time collaborator.

Now nobody will be safe.

April 23, 2005

Prescience?

An addendum to Randy’s observation below. This triggered a memory of something our buddy Crock once wrote. He said:

There are three positions you can take on inevitability.

  1. Passive ignorance.
  2. Futile resistence.
  3. Exploitation.

Sony is moving from Position 1 to Position 2. eBay is in Position 3.

He was talking about Sony’s announcement that they were going to ban the sale of characters from their online games. This was in April, 2000.

But, as Randy said, just because they’ve decided to embrace reality doesn’t mean they’ll necessarily embrace it successfully.

November 24, 2004

Thanksgiving Lasagna

For reasons which entirely elude me, it has become the tradition in our household for me to cook a lasagna for our Thanksgiving dinner. I think it may have something to do with giving my wife an excuse to make me cook, but in any event I make a pretty good lasagna.

The recipe I use is one of those recipes that has been passed from friend to friend over the years, mutating ever so slightly at each step. My contribution to this process came about 25 years ago when I was first learning to cook for real. My wife (then girlfriend) was teaching me, but I tried to lean on her assistance as little as possible, mainly because I tend to favor the Jump Straight Into The Deep End school when it comes to learning new things. This recipe seem pretty straightforward and self-explanatory, so I didn’t ask for a lot of advice. However, being a novice, I was unclear on the distinction between a clove of garlic and a bulb of garlic. The recipe called for a clove, but I chopped up a whole bulb’s worth and put it in. Janice, who insisted, despite my whining, on periodically checking my work in progress, tasted the simmering meat sauce and pronounced that it was pretty good but that it needed more garlic. I protested, and insisted that I had already put in an entire clove, holding up a garlic bulb as illustration. It was at this point that the magnitude of my error became clear. We learned three important things that day which helped draw our growing relationship even closer: (1) she really likes garlic, (2) I really like garlic, and (3) you know, it’s really pretty hard to have too much garlic, isn’t it?

Chip’s Lasagna

Meat sauce:
3 lbs. ground chuck (can substitute ground turkey for cheapness or leanness)
1 large bulb fresh garlic, minced
1+ tsp. Italian seasoning
1+ tsp. oregano
1 29oz. can or 2 15oz. cans tomato sauce
2 6oz. cans tomato paste

Brown meat slowly. Spoon off fat. Add other ingredients. Simmer at least 1/2 hr. uncovered (longer is better).

Cook 8oz. lasagna noodles as directed on package (rinse in cold water)

Cheese filling:
~2 cups Ricotta cheese (1 lb. carton should suffice)
1/2 cup grated Parmesan or Romano cheese
2 tbs. parsley flakes
2 beaten eggs
1/2 tsp. pepper

Mix.

Slice 1 lb. mozzarella very thin

Put 1/2 of noodles in 13″x9″x2″ pan.
Spread with 1/2 of cheese filling.
Cover with 1/2 of mozzarella and 1/2 of meat sauce.
Repeat layers.

Bake at 325 degrees for 45 minutes.
Let stand 10-15 minutes before cutting; filling will settle slightly.

Eat!

October 16, 2004

The Vision: Cyberspace Protocol Requirements

In 1993 Electric Communities was a three-person consulting partnership: Randy, me, and our former Lucasfilm Games coworker and frequent collaborator, Doug Crockford. We had several clients, but by far the biggest and most important was Fujitsu. Fujitsu had hired us to do a business plan for bringing Habitat back to the United States, starting from the Fujitsu Habitat system they had developed in Japan. This was the project that eventually became WorldsAway (and which they eventually hired us to staff and manage during its formative years).

We, for our part, were far less interested in Habitat per se, which for us was yesterday’s thing, than we were in newer, more cutting edge stuff. The biggest limitations in the Habitat architecture, from our perspective, were that it relied on a unitary, centralized server, and that the environment was not user extensible. We wanted to put together a system which overcame these limitations.

We had some ideas about how to do this. We were heavily influenced by lengthy discussions with Dean Tribble and Mark Miller, who introduced us to the wonders of the capability paradigm for security and optimistic computation for implementing distributed systems. Dean and Mark worked at Xanadu during the time Randy and I worked at American Information Exchange. We got to talk to each other a lot because, for about five years, AMiX and Xanadu shared offices in Palo Alto (both companies being part of the Greater Autodesk Coprosperity Sphere at the time). But that’s another story.

Our arrangement with Fujitsu was that they would pay us to spend half our time working on WorldsAway and the other half doing advanced conceptual studies, planning, and prototyping for a next-generation system. They’d own the WorldsAway work and we’d own the conceptual stuff, though they would have the right to make use of the latter however they wished. It was a pretty sweet deal, especially when viewed in the light of these post-bubble years. We got to sit around and think great thoughts about pretty much whatever we damn well pleased while getting paid rather well for our trouble.

For the most part, I worked on the conceptual stuff (with a little bit of WorldsAway), Randy worked on WorldsAway (with a little bit of conceptual stuff), and Crock worked on figuring out how to present all this weirdness to the people at Fujitsu. After a couple of years of producing various presentations, studies, and reports, the ultimate end product of this effort was a hefty document gradiosely entitled Cyberspace Protocol Requirements, which we post here in public for the first time. (Note that although this is the final revision of this document, dating from February, 1995, the principal work was published in the March, 1994 in a form only very slightly different from this.) This document is really quite embarrasingly dated, but we decided it would be worthwhile to get it on the record. It’s probably also worth pointing here to the manual for Dean Tribble’s Joule language, which was included as an appendix in the dead tree version of the Protocol Requirements document. Joule was our first round pick for the foundation language for the infrastructure we proposed building.

An important piece of historical perspective to keep in mind, should you actually attempt to read this: there is one seriously major development that had not yet taken place at the time this was originally drafted, namely, the rise of the Internet. The Internet was just beginning its explosive takeoff at that point; indeed, we allude to this. However, though people certainly expected that some kind of dominant, global, electronic network was going to be the wave of the future, at the time the Internet per se did not appear to be the foregone conclusion that in retrospect it obviously was. It was a time when all the various large media companies (phone companies, television networks, cable TV operators, etc.) were announcing mergers and new strategic alliances almost daily, in an absurd and furious spectacle that we referred to as “The Dance Of The Dinosaurs”. Nothing concerning the look of the future was very clear. It was a time when people were still getting used to the idea that commercial use of the Internet was even legal (which it hadn’t really been for most of its existence up to that point, since it had been a creature of the world of academia). In particular, we were getting along with FTP and Gopher and none of us realized the the World Wide Web would be the big winner. Indeed, those of us who had been associated with Project Xanadu were especially surprised by the success of the Web, since its technical deficiencies were, in our eyes, so profound that we never quite believed that anyone could ever take it seriously (as Mark Miller put it, “if we had known at the time that the thing didn’t actually have to work, we would have been done a lot sooner.”)

Another disclaimer is that there is a lot of visionary stuff in here that I either no longer believe or believe in a profoundly modified form. I’ll have a lot more to say about this in my next post, which I’ll have up here soon.