Reverse Jevons Paradox

Jevons paradox happens when the cost of a resource goes down, but the total spend on that resource goes up. It sounds like the total spend should go down since the price went down, but the decreased cost allows for more use within the same budget, and opens up for new families of usage: things that were previously net-negative because of the resource cost are all of a sudden net-positive¹.

A typical example is old cars and gas price. If gas is expensive, you'll take public transport to your work, you'll bike to your friends and family, and you'll walk to the grocery store every day so that each time it's not so heavy. If gas prices drop, it suddenly makes sense to drive to places to save time. You can bulk-shop, visit more remote friends and family, and you can even get a new job with a longer commute, since it is now economically viable to do so.

Jevons paradox is often cited in programming, both when the cost is monetary but also when it's time. If your build- and test suite is very slow, you might run it over night when you build the nightly build. If it's really fast, there's no need to limit it to once per day, and you can do a full build and a full run of the test suite on every commit. You can even do it locally before you commit, which means even more use. This is not just speeding up the build and test suite, it is fundamentally different from building nightly builds. Your CI bill, of course, increases.

This is all well known, but I've realized this effect also works in reverse: if the cost of a resource goes up, the total spend on that resource can go down. It can even go all the way to zero! I don't know if this has a name, so I'm calling it the Reverse Jevons paradox, even if it is less paradoxical sounding than the regular Jevons.

Say you're in charge of a big software effort. If you make it hard to change code by requiring multiple levels of reviews, a web of Jira tickets, a horde of people needing to sign off, and other red tape, you might effectively kill a whole class of changes, like "small refactor" PRs. The cost of making small changes to the codebase is so high that it becomes net-negative for a single developer to make the change. It is no longer worth the effort, and so they won't do it anymore. This is, of course, disasterous for the health of a codebase. This too is a fundamental difference, not a marginal change of rate. The codebase doesn't get the same stream of incremental improvements but at a slower rate, the improvements stop coming altogether.

Thanks for reading.

This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License