mht.wtf

Reverse Jevons Paradox

August 03, 2026<br>back to posts

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

A typical example is old cars and gas price.<br>If gas is expensive, you'll take public transport to your work,<br>you'll bike to your friends and family,<br>and you'll walk to the grocery store every day so that each time it's not so heavy.<br>If gas prices drop, it suddenly makes sense to drive to places to save time.<br>You can bulk-shop, visit more remote friends and family,<br>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.<br>If your build- and test suite is very slow, you might run it over night when you build the nightly build.<br>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.<br>You can even do it locally before you commit, which means even more use.<br>This is not just speeding up the build and test suite, it is fundamentally different from building nightly builds.<br>Your CI bill, of course, increases.

This is all well known, but I've realized this effect also works in reverse:<br>if the cost of a resource goes up, the total spend on that resource can go down .<br>It can even go all the way to zero!<br>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.<br>If you make it hard to change code by requiring multiple levels of reviews,<br>a web of Jira tickets,<br>a horde of people needing to sign off,<br>and other red tape,<br>you might effectively kill a whole class of changes, like "small refactor" PRs.<br>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.<br>It is no longer worth the effort, and so they won't do it anymore.<br>This is, of course, disasterous for the health of a codebase.<br>This too is a fundamental difference, not a marginal change of rate.<br>The codebase doesn't get the same stream of incremental improvements but at a slower rate,<br>the improvements stop coming altogether.

Thanks for reading.

Footnotes

If you pay $1.00 to press a button, and pressing the button pays you $0.99, you will press the button zero times. If you get $1.01 instead, you will press the button all the time. ↩

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