7 min read

Code as Contestable Law

If code is law, and law can be disobeyed, how can we make code more contestable?
Sign freading "Caution: Automatic Door". The word door has been crossed out and been repalced by "law"
"Caution Automatic Door" by SmartSignBrooklyn, CC BY 2.0

People tend to think of laws as set in stone, but they're very changeable. They're changeable in at least two ways: the laws themselves can be altered, through formal legal mechanisms like passing a bill through Congress, or laws can change through how they're enforced on the ground.

It's tempting to say that only the first of these two mechanisms is legitimate. We should always enforce all laws that exist! If we don't like the laws, we should change them, not disobey them! But the first mechanism actually relies on the second. We don't know what formal changes are necessary until we've seen people contesting the enforcement of existing laws.

When people disobey a law in order to draw attention to the importance of changing it, we call it civil disobedience. Or, as civil rights activist and longtime Congressman John Lewis called it, "good trouble".

In the language of interpretive labor, civil disobedience happens when people without direct power over a system recognize a gap between "how things are" and "how things should be" and decide they are not going to quietly bridge that gap but instead call attention to it. By making the problem a problem for everyone—or at least, a problem for more people—they increase the likelihood that the system itself will be changed.

A large group of protesters, largely Black, holding a sign that says "Black Lives Matter"
Photo by Montecruz Foto, Creative Commons.

Laws can also be contested by the people tasked with enforcing laws. We might call this "mercy".

Elinor Ostrom, in her book Governing the Commons, talks about a village near a forest that relied on cutting and selling timber. To keep the forest from being over-logged, the villagers had adopted rules limiting who could log what. But during dire economic times, people couldn't always follow those rules.

“Almost all the villagers knew that almost all the other villagers were breaking the rules: sneaking around the commons at night, cutting trees that were larger than the allowed size, even using wood-cutting tools that were not permitted. [...] The violators themselves tried to exercise self-discipline out of deference to the preservation of the commons, and stole from the commons only out of desperation. Inspectors or other witnesses who saw violations maintained silence out of sympathy for the violators' desperation and out of confidence that the problem was temporary and could not really hurt the commons.”

Mercy granted by those tasked with enforcing rules helps the system to be more tolerable, which gives communities the time and the mental and emotional energy to engage in fixing flaws more formally.

Contesting the Law of Code

Contestation is a vital part of governance. But software systems often make our governance less contestable, not more. Code automatically enforces itself, leaving little space for disobedience or mercy.

This is ironic. Code is so easily changeable*! It's a lot easier to rewrite a few functions than to pass a law and then communicate the new law to everyone in society.

Okay, fine, it's not that changeable. If you rewrite a function you've got to check all the other code that calls that function and make sure you've not broken anything, that there are no leaky abstractions, plus you've got to update your tests and your docs. But you can still do it faster than Congress can pass a law. Probably.

But how code works in theory is not the same as how code works in practice.

Working by myself on a solo project, I can reach a joyful flow state where I am constantly cycling between imaginative and interpretive labor. I have an idea in my head for what I want the software to be, I try to implement it, I test it out against the world, I see an error or something else unexpected, I adjust my mental model. I can and have spent days straight doing this. It's fun and empowering.

Immediate feedback is a necessary part of flow. So is control. But what works for a personal project no one else is using cannot work for a piece of software that impacts millions or even billions of people. Feedback becomes more varied, more overwhelming, and can take a lot of effort to gather. Control must be shared. Barriers are thrown up between interpretive and imaginative labor.

Many software companies exploit these barriers. The distance between the developers of the software, and the users of the software, is exploited to force users to accept certain interactions and exerpiences. (More on that in a forthcoming post about "dystopian software development".)

But even in the best case scenario, where software development is governed by users instead of shareholders, and all of these best practices and more are adopted, there would still be a delay between "suggest a change" and "adopt a change". And in the worst case scenario, there is no way to even suggest a change.

So where, in software, is there space for users to be disobedient or show mercy?

Designing for Contestation

This section contains some screenshots from a project of mine. Kybern is/was a project exploring how we can use technology to enable customizable, collective self-governance online. I paused work on it due to a lack of funding, but if the ideas behind it excite you, you might want to check out Amy Zhang's PolicyKit. Special thanks to the extremely talented Arty Rivera for helping me with Kybern's UX design.

One of my goals with Kybern was to make the governance actions that people take on websites more legible and contestable. To that end, every single thing you can do on Kybern creates a record. That record is searchable and automatically comes with a discussion space.

Gif of Kybern interface, showing a user finding an action ("adding a Bylaws document") and leaving a comment on it
Gif of Kybern interface, showing a user finding an action ("adding a Bylaws document") and leaving a comment on it

This is all well and good, but discussion is still limited to formally allowed actions. If a user can't take an action, they won't be able to generate the action object and thus the discussion space. They might not even know the action exists!

Most websites hide the actions that users can't take from them. There's a little bit of code on the backend saying, "hey, if this user has permission, show them this button, otherwise hide it".

That's not always the case. For example, when Twitter gave users the ability to turn off replies, they displayed a greyed out icon that, when you click on it, tells you that you can’t take that action. This is because people were expecting to be able to take that action, so they wanted to show people that they couldn’t this time. But this is the exception rather than the rule. Twitter staff have the ability to delete other people's tweets, for instance, but a regular user doesn't see a greyed out delete tweet button on every tweet.

This design makes it very difficult to know what actions are possible, and to contest your right to take those actions. I used this design initially for Kybern, because that's what I'm used to. But then I thought, "Does this actually empower users?"

So I switched to showing users all actions. Kybern also gives users an interface for "proposing" an action they don't have permission to take. When someone  proposes an action, they're required to write a little note explaining the context and why they want to take that action.

(It's worth noting that even if you have permission to take an action, you can still just propose it. So that's a way of getting feedback and community buy-in before you actually make a change.)


The proposal process creates space for disagreement or contestation. It can be narrow ("I just need an exception for this one action") or broad ("Why am I banned from doing this? All users should be allowed to do this!"). One can imagine trolls using this capability to flood a community with proposals, but there are other mechanisms for community management.

Now, this is not as far as we could go. We could also let anyone take an action, even if they don't have permission.

This is really antithetical to how we think about digital platforms, but it's not far off from how laws work in real life. You're not allowed to drive drunk, for example, but you can still do it. If we could somehow magically flip a switch and stop everyone from driving drunk, we probably would, but the fact remains that human societies mostly have laws that can be violated. So maybe there's value in a digital platform that works similarly.

Practicing Governance

A design and interface like Kybern's asks a lot of people. It requires an engagement with the practice of governance that most people are not prepared for.

But at the same time, we can't keep delegating all of our thoughts and decisions about governance to others. We let Facebook and Apple designers tell us how to use technology and we let elected representatives choose our policies for us, instead of engaging in the messy work of negotiation and compromise ourselves. Governance seems intimidating at least in part because we’re so out of practice.

And because we have so much else on our plates. So many of us live precarious lives, which means we don’t have the time or the energy to make these kinds of decisions. And the people we have to delegate power to, in Congress and in Silicon Valley, benefit from that.

But they don't have to accept how things are. We can contest it.

This post is based on a talk I gave at the IASC Knowledge Commons convening in 2021 (back when Kybern was still an active project). You can watch my presentation as well as a panel discussion with myself and several others.