Establishing facts on the ground

Even though I never actually read the book, Lawrence Lessig’s book Code and Other Laws of Cyberspace is often on my mind. The book’s argument that code and algorithms are rules as much as anything else should be always be in the back of the mind of every programmer.

Just look at the different kinds of content management systems out there. The rules for editing content in a wiki are very different than those for editing content in a weblog application, and those rules are the essence of those applications. It’s illegal to share copyright-protected digital media, but there’s lots of code out there that makes it easy to do so. It’s not illegal to watch DVDs from Europe in the United States and vice versa, but DVD players come with code preventing you from doing so.

For an application developer, one of the key considerations (that often doesn’t get considered) is what kinds of user behavior should be encouraged or discouraged. To put it in economic terms, when you build applications you have to think about incentives. For example, let’s say your application provides two features for notifying people of updates, an Atom feed and email notifications. If you want people to use the Atom feed, you hide the “subscribe to email” link in an obscure place and you put feed icons everywhere. There were a couple of items about managing user behavior on the O’Reilly Radar in May, one about Amazon.com allowing customers to provide credit card numbers over the phone, and another about profile photos at various social networking sites. Both looked at how user interface design affects how users behave.

Which brings me to my point. At work we have an application that allows people to collaboratively build a library of frequently asked questions, and it includes mechanisms for reviewing content for public release. It’s actually an application I’m pretty excited about, and that I’ll write more about later. Right now one of our big internal discussions is about who is allowed to view and edit which content, and what they’re allowed to do with it. There are two “code is law” related issues here. The first is that everything in our application is text, so if people can see the content, they can easily share it with people outside the system. That’s beyond our control. The second is that ultimately the code determines the model of participation for the system’s users. Do we allow anyone to edit anything, wiki-style? Or do we lock things down so there’s a privileged class of users who are the gatekeepers for the content? What model furthers the mission of our organization?

The most interesting thing about being a developer is that code establishes the facts on the ground. So even working within the requirements laid out by the organization, we still have a lot of leeway when it comes to establishing how people use the application. The question is whether we’re conscious of that and how we use it. At work, we’re wrangling with the requirements and building the application itself at the same time. The challenge is fulfilling the requirements and building something that enables our users to create the kind of community that we envision. It’s an interesting challenge.