Time, Effort, and Tragedy of the Commons

July 17, 2022

As I dive deeper and deeper into trying to figure out better ways to utilize the leverage I believe I have, I’ve started thinking more about the Tragedy of the Commons on a personal level.

The Tragedy of the Commons is a fun economic concept that can be quickly described as thinking a resource is unlimited without realizing that the resource is actually very limited, and the resulting consequences on that for everyone. I think this cartoon explains pretty well:

You can make this analogy in software pretty easily, even if the resource is less tangible than something like water. For example: everyone uses open source software (OSS). Everyone thinks OSS is awesome and free and generally works, but when the package doesn’t work, it’s time to spam the maintainers. Often, you will see issues like this:

This is a classic Tragedy of the Commons issue, where the resource you are drawing on is not the OSS package you are using, but the software maintainer’s time. As conscious beings, time is our most valuable resource! Who says the maintainer even wants to spend it fixing a bug that might only have consequence to you, especially if they’re doing it for free?

And imagine that the maintainer has dozens, hundreds, maybe thousands of issues like this they need to respond to. Without more maintainers / good samaritans who can help out, you might be out of luck on the thing you need fixed.

Another example that’s more company-based is thinking another team has the bandwidth to do some extra thing that’s related to your project, but not considering if the other team actually has the bandwidth to support an extra process at the moment. I can’t tell you how many times I’ve written a runbook at work, where one of the line items was, “Oh, and Support should do this” without considering if Support has the time and capacity to actually do the thing I’m describing.

Your own time is also a resource

Viewing time as a resource is a really good way of flipping not only how and what you communicate to people, but also how you view your own time. From a software individual contributor (IC) perspective, we’ve all fallen into the trap of creating technical debt and papering over it by saying, “Oh, I’ll just come back to it later and refactor”.

How many times have you actually come back to it later? How many times have you left a project, team, or company permanently after that and the code is now just there, in perpetuity?

I can’t speak for everyone, but this happens to me constantly. FWIW, it’s not “wrong” that anyone does this - I would think the average engineer actually does this a lot. But in a way, viewing your own future time as a limited resource you’re constantly drawing on is a way of reorienting how you think about if it is really worth it to just do the right thing right now. To say you will do something or refactor something later is banking on that you have the time and the context later to do it the way you envision now.

One important caveat I want to make: this is not an argument for doing something the right way all of the time, because the argument easily works in the opposite way. Let’s say you’re a software craftsman and you want to make the most perfect code anyone has ever seen or written, and it’s your mantra to do this for every line of code you write. But let’s also say having this mantra means you spend much more time than your peers writing something that could’ve been written 2x faster (maybe messier), with much less thinking involved.

You are, in this case, drawing heavily on the time you’re spending right now, when you could’ve been spending that time doing something that created more value than craftsmanship-like code (aka an opportunity cost).

Balancing how you spend your time

I like to think there’s a balance in-between these two arguments that are ultimately arguing for the same thing. We’re basically constantly on the tightrope, trying to balance the time we’re taking now with the time we think we have later.

Another way of thinking about this is the following: if you had a bank of time, how would you spend it, and can you raincheck your time or are you overestimating how much you will have in the future?

How do you make sure you’re spending the little time you actually have, doing the most important and impactful things?

Ultimately, we want to make sure we’re spending more quality hours doing fruitful things that have value either to the world or to us. Your time is your most valuable resource, more than money. If you treat it as such, the balancing of what you do now and later will come naturally, whether it’s in software or other things you want to get done in life.