I’ve been thinking about the Tragedy of the Commons a lot lately, and how this concept applies to software development. The tragedy of the commons is what happens when there’s a shared common resource that everyone must use, but no one has ownership over. Think public parks or grasslands that have no designated owner or care-taker.
This tragedy begins when you have an overuse of the shared resource. Cattle grazing on unowned grasslands isn’t a problem until there are too many cows. Resources become depleted because too many people are acting in their own individual interest.
I had to learn about this concept when I was studying economics in college. When I first learned about it, I didn’t realize that it would be so applicable to so many problems I deal with on a daily basis. This is especially true in software development, both in code and in systems as a whole.
One example of a shared resource in software might be your continuous integration server. A CI server is a resource that an entire development team shares. It exists to exercise your software continuously and helps developers and stakeholders stay aware of changes going on within a system. If you’ve implemented CI correctly, it acts as a valuable feedback mechanism for the whole team.
CI is quite easy to setup and use when working in the context of a small group working on a small system. What happens when your system is large and your team of developers grows large as well? Everyone used to feel responsible for the build, and now its turned into a crowded mess. No individual on your team can be pinned for polluting the build. Instead, the collective pollution over time in many different parts of the codebase are what leave it with a generally strange odor. It’s frustrating to not be able to pin the problem to one person. It’s human nature to try to find a single troublemaker who’s put everyone in the mess. Your team didn’t pollute the commons all at once, but little bits of unnoticed garbage were sprinkled into the system over time.
It’s like comb-overs, as Paul Graham talks about them in The Age of Essays. No one goes to bed at night with a full set of hair and wakes up the next morning with a comb-over. It happens gradually, within small moments of time.
You’ll start to see other examples of the tragedy of the commons pop up in places you didn’t expect. Your database schema might start to drift from something organized to something chaotic. Or perhaps your background job processor starts to get overused and under monitored. When things were simple it was easy to make everyone feel like they owned part of each of these systems. Now everything is bigger and more complicated, and all of your success is tied to the success of these systems working smoothly.
So how do you fix the tragedy of the commons? It’s quite a tricky problem if you ask me. To be frank, I have no silver bullet to offer you; it’s called a tragedy for a reason. What I do want to offer you are some ideas that have helped me think about the commons with a clearer perspective.
I’ve had to develop a personal appreciation for the commons and seek to internalize ways that it benefits me. This has to be the first step. If you can’t first understand how a clean and functional commons benefits you as an individual, you’re never going to have an impact on making it better. It’s how you start to internalize ownership. Everyone must feel that the commons contributes positively to their work, and that their life would be worse without it.
In a similar way, everyone must feel empowered to change and clean up a problem when they see it. If you don’t put trash cans at the public park, no one is going to throw away the garbage. This is why software engineers should favor simple system designs. Simple designs lead to lower barriers of participation. Lowering the barriers of participation means that everyone can understand the system enough to make it better when necessary.
Ultimately, it’s still about the individual. Everyone must feel individually responsible for making the collective better. Rules and policies will always crumble in the face of individual responsibility. Once you realize that it’s up to you to make the whole better, it becomes easier to roll your sleeves up and get to work.