My lightning talk about Software Development and Tragedy of the commons (“Kollektivt kodägarskap och allmänningens tragedi – eller hur blir min kodbas inte utfiskad) from Agila Sverige 2013
And here is the video recording from the event. My presentation begins 12 minutes and 10 seconds into the film.
Here’s the (almost word by word) english transcript of the speech:
Nowadays I work with management consulting, agile management consulting. I help companies turn upside down and go from hierarchies to, well, an upside down hierarchy, and hopefully eventually to become more of a network. So, probably it’s more un-management consulting I work with.
When you work in organizations you work with resources, and resources that involves many people. And while doing that I have discovered something. I have a hypothesis I want to present today. Lets see if you believe me or not: code is a “common”.
Commons are however, not without problems, which you can see for example when you work with collective ownership of code.
What is this? These are public goods. Economists at least call them that. They are completely sharable. If someone arrange a firework, everyone can benefit from it. It’s hard to get people to pay for watching firework, its a public good.
Then we have these kind of goods. What do we call them? Private goods. If I eat the bread, no one else can it it. There’s no conflict around that. Or, well, there is a conflict of redistribution, but let not go down that road now.
Then there are these other kind of goods, sort of a go between. Many share the same good, but at the same time you are consuming it, which means you have to reach an agreement on how to consume or use the resource somehow.
And, unfortunately, this is hard. Already Aristotle knew this. ”For that which is common to the greatest number has the least care bestowed upon it. Everyone thinks chiefly of his own, hardly at all of the common interest; and only when he is himself concerned as an individual.” A sort of egoism, you could say. This creates a dilemma if you have a common.
This is Garret Hardin. He was a professor of biology. He wrote a paper in 1968 with the title “Tragedy of the commons”, which is very pessimistic. In short he says: if there is a common, it will fail miserably. The basic reason is that at a common, the economic value of an activity is not shared equally.
Lets look at a common. We have a meadow. We have some cows. And then some farmers. One farmer wants to add a cow to the common. When he sells the cow, he get the complete meet value for the cow. But the cow has been eating from the meadow. The cost for that is however shared by everyone.
And that is the tragedy of commons. How can we regulate this? As I said, Garret was very pessimistic: “Ruin is the destination toward which all men rush, each pursuing his own best interest in a society that believes in the freedom of the commons”
This was not something Garet came up to just by himself. It’s well grounded in economic theory, and especially game theory. Mathematicians and economists have talked a lot about this. Mancur Olsen, for example, when he writes about collective actions.
I will, however, not delve on this topic, since it would take too much time. But I just want to mention the prisoners dilemma, which you surely have heard about before, which shows that rational choices does not fully work (i.e. give the best welfare). If we, in the example, have to make choices without being able to communicate we will end up in a less good choice compared to what we ought to chose to maximize utility. We get 2 years in jail instead of 1, in my example here.
Or we have the free rider problem (which biking in many ways is about how to handle). There are lots of situations where we do not have mechanisms to handle this problem.
Total privatization. You remake the common into a bread, something only I can eat.
Or you need a Leviathan. To solve the collective action problem you need an ousider that can force decisions on the individuals that are action on the commons. That way you can solve the prisoners dilemma. Someone from the outside forces them to shut their mouth (get one year).
Here’s one of the many voices on this: “Hierarchy is the price people may choose to pay for efficiency in groups”,
At an agile conference like this, I guess we all think this is kind of moth. And you probably even have experiences that collective ownership actually works.
But there is also another fundamental problem with hierarchies. If we are in a complex domain, it often means that the ones having the real knowledge is the one acting on the edges, the users or actors. In an hierarchy you must first gather knowledge, then send it up the pyramid, make a decision and the “send” it back down the pyramid. Three bad things happens:
- I will know to few things
- I will know them too late
- And when the decisions are about to be implemented they will not be viewed as legitimate.
Hierarchies are in them self problematic when making decisions in complex environments.
And these (the commons) are complex environments, such as fishing or irrigation systems. This is a bridge in Dalarna. This is a common, that has been successfully handled by a local association for a long time. It works fine.
Works fine? How can that be? We have commons that works. Something is fishy with the economists view that commons do not work.
But, there is this woman named Elinor Ostrom, which has done research on this. Her research has its roots in the same tradition as rational choice, but she asked the important question: how does it actually work, out in the reality? She did, and got the nobel prize for that. Read her books.
I think we have much to learn from them on how to handle commons code bases, for example, we need:
- Clearly defined boundaries – you need to know where the boundaries are. You need to be able to shut people out. You need to be able to know precisely which are on the inside.
- Rules for usage and maintenance are adapted to local conditions
- Users, such as a fisherman or a coder, can participate in the decision-making process
- Effective monitoring by users themselves. Overlooking the other parties actions should be built into the process itself. Why have you put your net at this location today you must be able to ask your fellow fisher?
- Graduated sanctions built into the system that are adapted to local knowledge and situations, and starts with weak punishment and increases. If my neighbour did not have food on his table, it might be OK that he took my fish this day. He should not immediately end up 10 years in prison. But when he does it for the tenth time, then punishment will be much harder.
- Mechanisms of conflict resolution that are cheap and of easy access and built into the system.
- Self-determination of the community recognized by higher-level authorities. Locall formation of the processes and rules, bottom up, must be view as legitimate higher up in the hierarchy, in a company for example. In practice, this means that things must be decided and formed from the bottom and up, and it must be OK from the top and down. But you can not govern or decide from the top down. Those kind of commons never work.
- In the case of larger common-pool resources, organization in the form of multiple layers of nested enterprises, with small local CPRs at the base level, that is: to handle larger common we nest meeting places, from the bottom up.
If you are a little cross functional team of say four persons, and you have your own code base. No problem. You stand around the whiteboard and “control” each other every day and contribute together to the code base.
But if you are bigger, say 10 teams, 15 teams, 20 teams, have big code base, where you build a common system, then these rules apply.
I add my little piece of code to the code base. I get full value from it, as a developer. But the cost of my addon, such as increased complexity, technical dept, dependencies which makes it harder for other to change their code, are shared by all using the code base.
So, a code base is exactly like a meadow where cows are eating the common gras. When we use the code, or makes changes to it, we enter the realm of the tragedy of the commons. And, therefore all code developing organization need to learn from Ostrom and here 8 design principles.
(There are of course many more commons in organizations, but that is the topic for another speach)