Jevons paradox and greening software—why increasing efficiency makes sense

green-software sustainability

July 31, 2024

Jevons paradox and greening software—why increasing efficiency makes sense

In discussions concerning software efficiency, the Jevons paradox is one of the topics that creeps in regularly. Every now and then, when I talk about green software, there is someone who asks: “Does it make sense to increase software efficiency if it will just make us use it more?”

It appeared again during my recent guest lecture at Harvard University. I was talking about the SCI (Software Carbon Intensity) standard; it’s a measure of the rate of emissions for a piece of software for example, carbon per user for a website.

So, the short answer is yes, we should make software more efficient. Writing better, more efficient code will help us reduce software emissions, and this is even more true when we use software at scale.

Let’s take a step back.

At the end of the 19th century, William Stanley Jevons observed that increasing the efficiency of coal use prompted by the invention of the steam engine didn’t lead to using less of it. On the contrary, it increased the consumption of coal across industries. What’s important is that the higher efficiency of the machines made the extraction of coal cheaper, which, in turn, affected accessibility. Hence, more people started using it.

The phenomenon, also known as the Rebound Effect, has been broadly examined by economists over the last century, and it has played an essential role in the discussion concerning energy conservation.

One of the recent episodes of Environment Variables examined the rebound effect and offered some interesting examples. The phenomenon resurfaced during the two oil crises and multiple times since then, but it can also be linked to remote working and online shopping, to give a few examples.

In the early 1990s, the Jevons effect was reformulated as the Khazzoom–Brookes postulate, which stated that “energy efficiency improvements that, on the broadest considerations, are economically justified at the microlevel lead to higher levels of energy consumption at the macro level.”

What’s important is that saving resources or using them more efficiently increases the use of the commodity in question. Resources can relate to a number of things, both material and non-material, such as energy or time.

So, how does this apply to software?

Before coming to the conclusion, I did a thought experiment and compared software and food. In our pursuit of making food healthier, do we ever worry about people eating too much of it? We put in a lot of effort, money, and resources to convince people to eat healthier, improve the quality of food, and make it more accessible. Nonetheless, none of this has an effect on the consumption of too much healthy food.

We don’t worry that making food healthier will cause people to overeat. So, should we be concerned that making software more carbon-efficient will lead to increased usage?

Let’s draw a connection here—is making software healthier and code better going to increase how much we use it?

The main reasons why we eat more of certain food products are:

The food consumed the most is the cheapest, and we can also argue that it is the most profitable. If we look at the food example, making products cheaper increases consumption, but making them “healthier” doesn’t.

When applied to software, it’s the cheap, addictive, and profitable software that drives consumption. I don’t think “healthy” software, such as software with a low SCI score, leads to overconsumption.

If we linked money (the means of monetary exchange) to carbon emissions, we could argue that the SCI could have a direct impact on increasing emissions. Still, in this case, we would have other measures and limits in place to reduce emissions.

If our economy were based on carbon (similar to how it used to be based on gold), even if making software more carbon-efficient created an incentive for increased consumption, central governments could reduce the supply of “carbon-money” each year to help meet emissions targets.

There is not enough evidence to prove that making software more efficient will increase how much we use it and that it will have an impact on software emitting more. Some claim that we must consider the rebound effect in software on a case-by-case basis. Still, the effect would only apply if there are other benefits of increased efficiency, such as lower cost.

While I believe that increasing the efficiency of software is a good thing in general, the reality is not black and white. Tom Greenwood argues, and I can’t help but agree with him, that as computing power increases and we develop more potent hardware, the control is in our hands. As software practitioners, we may choose to maintain an efficient approach, using the resources in the way they serve the purpose best. Or “bloat” the code and use all the new power that is available. However, in this case, we shouldn’t be talking about efficiency anymore; we should be talking about waste.