Monthly Archives: March 2004

Situated Software #2

Leave a reply

A conversation with Brian reveals the interesting insight that many products emerge first as situated software; to use Clay’s delightful term.

Consider for example MovableType. It emerged situated in the intersection of the set of people that could install Perl and the set of people who manifested a desire to rant (or reveal). For the longest time that community of people both limited it’s growth but at the same time forgave it any number of short comings. Finally the folks who wrote it budded off TypePad which eliminated a the Perl expertise portion from the embedded situation.

If you want to get dragged into conversation about membrane design again then you can turn up the knob and rant about how that’s another example of how public goods can be captured by private entities. But that’s somebody else’s rant.

All this is analogous to Clayton Christensen’s rants about how disruptive products seem to always emerge serving unserved customers. Such customers are both forgiving of the products short comings and they provide a strong demand signal that helps to shape the product that emerges. Both of these are necessary preconditions for creating something new.

Oh no, there are now two dudes named Clay in this posting; what’s up with that!

In any case.

Another point to make about situated software is this balance between a forgiving environment and a strong signal that helps the software to adapt.

“adapt” – I stole that from Stefano.

The challenge in making a thing survive over time is getting it to adapt.

So among the benefits that a piece of situated software draws from it’s environment is this adaptive advantage. More forgiveness. Better feedback.

One reason that real world software is so much harder is that it’s unforgiving. One reason that Windows has thrived is that they have demanded a high level of forgiveness from their users. They get to do that because of the monopoly.

Economists should stop being so fixated on the pricing advantages a monopoly captures and turn their attention to the adaptive advantages. Oh wait, I’m getting dragged back into the membrane design discussion; I hate that discussion.

Situated software

1 Reply

Clay’s new essay about what he calls situated software is very important. He is saying something new about software. I don’t think he’s run the idea to ground yet, which makes it even more fun.

He says the idea arose out of observing how his students executed an assignment – build a web app useful to our local community. The key insight was that some of these applications leveraged the complement of that assignment – build a web app that makes use of the local community.

Clay is close to asking a question that I’ve been puzzling about in various forms for the last few years. If we embrace that group membranes are a good thing then what kinds of things are possible inside of the membrane? It is hard to get to this question since so much energy is devoted to worrying over the membranes.

Clay frames that question by introducing the idea that there is a class of software that we could call “situated software.” Software that’s inside the membrane. Software that is dependent on the social contract or physical reality it runs inside of. He contrasts this with what he names “web school” software; i.e. software designed to run in cold cruel world, the globalized, firewall free world. That other world is, of course, interesting because the huge audiences create the chance at minimum of drawing on a huge sample space of users, and at the maximum of spinning up huge network effects. But yeah! Ignore that. What if I want to create software that empowers huge numbers of groups.

You can reduce what Clay’s saying in this essay; should you want to, by could mapping it into various conventional frameworks. Nothing wrong with that, as long as we take care to avoid killing the baby. Clay even does some of that in the tail end of the essay.

To some extent the idea is like personalization; i.e. software that adapts to it’s users. To some extent it’s like localization; i.e. software that adapts to the culture of it’s users. To some extent it’s like the things that we too casually repeat about the democratization of software development; i.e. that exciting things happen when users are empowered to author their own solutions.

I have gotten a degree of milage out of that last one. It gives you a long series of historical events you can pick apart. In each you can look at the social unfolding of what happens when software becomes more local. Lots of examples: minicomputers, PCs, spreadsheets, desktop publishing, drum machines, Hypercard…. Clay’s essay makes me tempted to go back and think about each of them again as a “localization event,” as enabling situated software to emerge. That’s more inward looking, which is what I want, than my usual model for these, (i.e. undermine the ivory towers).

He talks about how one of the student applications, a market making app, could skip having to build the module we find in market-makers like eBay which try to reify the buyer/seller reputations. His student’s applications could gloss over that because the local community’s reputation system was already available. It was in the platform so to speak.

That reminded me of how often I’ve encountered in-house one of a kind systems with no training materials what so ever. You do occasionally hear complaints about the lack of training materials (or doc); but generally the social networks of the organization are entirely sufficient to make up for the lack of doc. In fact I’m reasonably confident that the lack of doc often turns out to be something of a positive for both the local social network’s health and the applications in question. At minimum it makes adapting the applications easier. Documentation has a tendency to be like a coating of varnish making an application shinny and immovable.

Similarly he talks about another sample application where the problem of how to manage the dialog with your users is solved by physical presence. In what he calls “web school” or real internet application that problem bleeds into the entire can of worm around email preference management and privacy policies. Who in their right mind asks their bank to send them more email?

In the example he gives the students built kiosks put them in a public space, devices with minimal UI. Both the minimal UI and the use of public space are things I’ve noticed too. The first time I noticed it was with spreadsheets – an early success at software democratization. You would not believe the percentage of spreadsheets that contain no calculation what so ever; instead they live their lives as ritual artifacts placed on a table in a meeting. (information radiator, is a similar story).

Thanks Clay!

Hair on Fire

Leave a reply

I see that Kevin Drum is reenforcing the hair-on-fire meme around Richard Clarke’s testimony. He stoops to suggesting Clarke is suffering from “monomania.” Kevin even signs on to the “clinton-bush-same-policy” meme.

How can Bush and Clinton have had the same policy if Al Quida was the #1 or #2 foreign priority of the Clinton administration while the Bush administration didn’t manage to have a meeting about it until September? How can they be the same policy when Rice’s essays on what is and isn’t important leading into up to their take over barely even mention terrorism and when they do it’s only in the context of state sponsors.

The hair-on-fire meme is the most serious accusation, but it’s only one of many so far. So far, the opponents of Mr. Clarke have suggested he’s gay, and that he’s picking on a black woman, that he’s a lier, a opportunist, … we could go on. So possibly we shouldn’t be too concerned if the mud that sticks is that he is a “true believer,” a man with a mission. But I think that terribly misses the point.

I’ve been thinking recently that one aspect of this story is how a liberal organization v.s. a conservative one responds when a guy enters the room and announces there is a huge unrecognized problem. For a liberal organization the response is “Sigh, another constituency. Ok, tell me your story and we will see what we can do.” For a conservative organization the reaction is “Calm down my son. Your problem is covered in our model, which has worked for years and will endure for many more.”

So it’s entirely consistent that Clarke was able to get a hearing and make his case in the Clinton administration. In the Bush administration he was considered just another one of those people with their hair on fire.

When ever any large institution changes course the social network of the people involve will have people out in front of the change and people that lag far behind and cling to the old ways. The folks out in front are always characterized as being over the top. Recall that enthusiasm was, until recently, a sin: to believe yourself full of the breadth of the lord. What distinguishes a healthy organization from a stagnant one is that it manages to filter thru the various enthusiasms and integrate in the ones that it must.

Institutions that fail to adapt act progressively more and more dysfunctional as the world around them changes and they don’t. At first this dysfunction is indistinguishable from all the usual background noise of the real world. In time it becomes sharper as the mismatch becomes more severe. Finally it is fatal.

It is clear that the Clinton administration was adapting and it’s clear that the Bush administration was not. Further it’s clear that as the signals from the real world became stronger the Bush administration retreated into their classic old models of how to address the problem.

There was a failure of the Bush administration to pick up the ball from the Clinton administration. Worse yet when they finally found the ball on fire on their front door they reacted by heading off in entirely the wrong direction. Feeding the supply chain of the terrorist networks with huge pool of outraged young men.

Ok so now we have a guy, Clarke, who was one of the folks on the fore front of trying to get the institution to change. He labors for years to help the ship of state change course. He makes significant progress. He suffers a set back when the new administration arrives. Over the months it becomes clear that he’s not getting thru to these people. They are deeply loyal to their model of the world and he’s not managing to get their attention.

Then the horrible day. No longer is his hair on fire, now the lawn out front’s on fire. What do they do? They go in entirely the wrong direction.

What would you do at that point? He did exactly what any well practices organizational specialist would do. He engaged in “object shift.” He looked for a different venue in which to make the case. This time he shifted the discussion to the public sphere. Is that excessive enthusiasm, monomania? No that’s effective workman like organizational grunt work.

We owe this guy a huge debt. To engage in projection and suggest that he’s suffering from narrow minded religious passions is the worst kind of insult. It paints him with the same brush we might appropriately select to paint religious terrorists, the oklahoma bombers, and possibly even the neo-cons.

Information Radiator

Leave a reply

What a nice term this is: Information Radiator. I’ve often very successfully solved some organizational problem by creating just such a device. More than once I’ve improved the quality of a large piece of software by just creating a concise report of current status and placing in someplace were people would notice it. The trick, from my point of view, is less to collect the data than how you manage to present it. The less ink the report uses per item of information the better. The more the report shows change or summary scores the better.

But the best thing about that term “information radiator” is how it so nicely sums up that you want something that’s not to hot not to cold. Something that changes the temperature. Something that draws attention to it’s self; but doesn’t burn.

(via Brian Marick)

Lisp Machine Video

Leave a reply

Rainer Joswig has released a 44 Meg Quicktime video showing some of the features of the Lisp machine. I found this extremely nostalgic. The Lisp Machines did all this in the middle 80s; and large portions of it in the late 70s.

The announcement in his blog implies that this is one of a series so he may have already said some of the following.

One thing to note is the integration of four interface styles. One style is a classic editor development loop. The second style is a rich graphic user interface; you need to wait till the little demo of the drawing editor to see that kind of UI. The third is an semi-english language like interface; you can see that in some of the commands he types.

The fourth, and this one is waiting for somebody to rediscover it, is that everything that is rendered into the output typescript retains knowledge of what type it is. That allows the mouse to move over the transcripts and everything that was output is “alive.” For example when his mouse moves over a symbol the system knows that it’s a symbol and the menus offered are appropriate for a symbol. This is, no surprisingly, true for small small types and large types. So when his mouse moves over the print out of, say, a system definition the menus then offer up operations like patching that system.

All four UI stand on a single foundation; a bridge between the dynamic type of the objects in the system and various “presentations” of those objects into the UI. Interaction is then intermediated by the nature of those presentations. That allowed you to write commands that would be offered up to the user when a given gesture was made on an object of a given type that appears in a given style of presentation.

You can see some of the notation for that in the simple examples he goes thru. The first few examples differ only in the kind of UI the interaction takes place within.

The demo ends with an example of the integration of source control the mechanisms for patching running systems. These are the kinds of systems that we are now having to rediscover to be able to respond quickly when hackers find security flaws in our running systems.

Dear Old Hypercard; farewell good friend

Leave a reply

hypercard

Tim Oren writes a nice little Eulogy for HyperCard.

A few things stick out in my mind about Hypercard.

It was incredibly fast. Software today rarely seems as fast. It could do a page turn faster than my G4 seems to be able to type a single character. It did could do these sweet builds from one page to the next that continue to this day in presentation software. You never saved data. That reminded me of APL workspaces.

It was one of the first applications to take seriously the idea that behavior might be inherited not in via the type/subtype hierarchy but via the document enclosure topology. So a button that when a button invoked the function F hypercard would search for the implementation of F first in the button, then the page, then document.

Tim points out that Hypercard wasn’t broken into client and server as we would likely do today. More important to me at the time and still today was that there was nothing you could do in the UI that you couldn’t do in the scripting language. That made it possible to do all kinds of very sweet animation on top of the amazing painting engine. This design pattern of a strong deep data type with a scripting engine laid over it is very powerful. You see it in Autocad, Emacs, and Excel. A lot of software these days the only deep data structure is – tada: the database. That gets dull pretty quickly.

When the Mac first came over the wall in 1984 I was fascinated by how it empowered a huge population of people to use computers. For the first time you really could bring one home and get to work writing that novel. A lot of people complained that the machine wasn’t friendly to programmers, which struck me as totally missing the point.

So I got curious about how you might empower a large population of people to program. Could you create the same event over again, this time enabling people to write software. The only example of even coming close at that point was the spreadsheet.

Hypercard did exactly that. It never competed with the installed base of developers. Instead it generated this amazing bloom of new tiny little applications. Instead it illustrated what happens when you manage to hand a useful tool over to a large unserved population of amateurs. The tail of the power-law curve.

I wonder, if flash is the closest modern equivalent; maybe so.

Adverse Selection

2 Replies

Adverse Selection is a term used in the insurance industry for a particular kind of market breakdown. The breakdown proceeds in a cycle where the distribution of customers shifts toward higher and higher risk buyers while the insurance company keeps raising prices to compensate until the only buyers who buy are truely horrible risks.

In all markets buyers and sellers have differing amounts of information about the goods being exchanged. For traditional manufactured goods sellers tend to know a lot about the costs of production while buyers tend to be better informed about the benefits they can capture after purchase. I.e. buyers tend to know more about the future and sellers more about the past.

Transactions are more likely to take place in the presense of these information asymmetries. If the buyer and seller have different models of worth then after the transaction has closed both parties can be happy with the outcome. If they have identical models then the best they can do is close the transaction with both parties meerly satisfied that they didn’t get taken. To an optimist this means that markets make everybody happier; to a pessimist it means that any transaction leaves money on the table.

The adverse selection senario given above is interesting because both buyer and seller are attempting to predict the future. A successful insurance company manages, thru the magic of statistics, to gain an upper hand in the information in balance.

One of the definitions linked to above gives this very concise definition of adverse selection: “A situation in which market participation is a negative signal.” Anytime a buyer or seller enter a market and begin to participate they reveal some information about the hand they have been dealt. When a market begins to fall apart via the process of adverse selection the market becomes structurally flawed so that only customers who are truely lousy risks will still enter the market. Once this happens then entering the market tends to signal that your a lousy customer.

Market structure creates selections pressures on both the buyers and the sellers. A market maker strives to maintain markets were these selection presures don’t drive the market in any of many the wrong directions. So while a “adverse selection” is a term used in the insurance industry it certainly would seem to be equally applicable to any number of other markets and in all cases it would seem to apply to both buyers and sellers. If the market is poorly structured then as tranactions clear the buyers and the sellers are both happy; but as the future unfolds one or both of them become unhappy.

Arrogant Software

Leave a reply

I love this quote.

Part of the problem was how arrogant we were. We believed that we could spend a couple of days watching trained lawyers perform a highly-skilled job, talk briefly to them, and then make their jobs completely obsolete.
– here

It resonates nicely with the fun that Clay’s been is having tearing into the social software dudes; even if I don’t entirely agree with him.

When I young I used to go to parties with lots of artists and theater people. They would ask what I did and upon replying that I wrote software a painful silence would follow. I’d sometimes indulge myself by inserting toward the end of that silence the assertion. “My dream is to put an entire city of people out of work!”

In reality my dream is to create new cities of people. Don’t tell anybody; but a lot of that arrogant social software seems to be doing just that. Who’d a thought, weird huh?

Serving up the self.

Leave a reply

Back to the Internet identity problem; or how we solve to solve the problem of letting users safely and easily reveal personal information, as well as the problem of how that interacts with various authoritative entities.

In the real world we reveal substantial amounts of information casually – hair color, language, approximate age, various fashion statements. We adjust that revealing dynamically. We wear different clothing in different contexts. For better or worse the folks around us use this revealed information to assemble a model of who we are. They create a model of our identity. The revealing is feeds into a dialog about their model of us. That model then feeds into our relationship the one between us.

In a commercial context we might call those relationships “accounts.” In the marketing literature they even talk about relationship marketing. Doc. Searls makes the point that as the Internet shifts the balance between them and us markets become conversations. Solving the identity problem is all about finding a way to enable that conversation to proceed in a practical, useful, and safe manner.

In the Internet no standard methods exist to help users begin the conversation. When I walk into Amazon, or eBay, or a mailing list I am naked. Actually it’s worse than that. I’m actually so thin a presence that I don’t even have a place to hang a few rags that might help me to project a persona.

Dog wearing a tie.
That didn’t happen by chance. Fixing the identity problem demands that we tackle two very hard problems (revealing and authorities). These are so hard we have kept pushing the problem outward. At each round in the design game it has been easier to just minimize the revealing and push the authority problem out to the network’s edges. That approach has its benefits. Nobody knows you’re a dog, America is all about second chances, etc. etc..

But I want to be wearing clothes when I go out. So today’s puzzle is to look at what a revealing mechanism might look like, from 40 thousand feet.

I find it amusing to say that what’s needed is a “self-server.” A place we can refer others to. Want to learn about me, go here. This place enables them to have a dialog about who I am.

Let’s look at a scenario.

I visit a Wiki. I want to contribute some fresh content. The server running the Wiki wants to check out my reputation before it lets that happen without moderation. So it turns around and via some Rube Goldberg device it manages to get access to my self-server and using that it asks about my reputation as a contributor of reasonable content. Since Mr. Wiki doesn’t trust me, of course, it’s pleased when the self-server recommends an authority that the Mr. Wiki can trust. Ask them Mr. Trusty says. Of course when asked Mr. Trusty (a reputation authority) says very nice things about me! Happy day, Wiki server let’s me post.

Clearly a lot of details are getting glossed over here. But notice that at no point was anything revealed about me except my reputation as a contributor of open content. The Wiki didn’t learn my name, or my social security number, or the name of my dog. Presumably before I’d allow my self-server to do that I’d have to grant permission.

If this were 1980s the self-server would be documented with an RFC and a simple protocol. In the 90s we might have used a web page, and if we wanted to encourage a dialog it would have included a CGI script. These days we call it a web services listener. “Whatevvver.” We modern guys so we can assume lots of encryption and opaque identity tokens etc. etc.

In the Liberty Alliance design this thing I’ve called a “self-server” is a set of web services spread out all over the Internet. That allows, in our example, lots of posting reputation services. It allows many many authorities of varying kinds and seriousness. Your bank, your house, your hairdresser, your clubs can all play a role. That’s as it should be. We certainly don’t want to create one grand central authority.

The only “central authority” they need to rendezvous with is the standard protocols. Those protocols break out into two layers. One is generalized glue that helps you find various kinds of services. The second is a suite of services. Once you get the first layer right then any number of members can pile onto the suite of services. If you want to have service that helps users reveal their fashion preferences then have at it.

Well actually there are three layers of protocols because we also need to design the Rube Goldberg device that helps you find the self-server-directory starting from what ever is available in the legacy protocols.