Increases in efficiency tend to increase rather than decrease consumption

Increasing the efficiency of using a resource for the sake of conserving it often backfire by increasing the demand for it. This is known as Jevons’ Paradox, which this video from Jess and Kent at systemsthinking.dev introduced me to.

The English economist William Jevons observed in his 1864 tract The Coal Question that technological advances which made it more efficient to burn coal in existing industries led to coal (and steam power) being used in new industries due to the lowered economic barriers to entry. And as Jess and Kent point out in their video (with a Causal loop diagram), this increased efficiency also grows the economy as a whole, leading to further increased consumption in a reinforcing feedback loop. So if you want to reduce the consumption of some limited resource, increasing the efficiency with which it’s used is not a good long-term strategy. Rather, introduce substitutes and make them more efficient.

While Jevons’ paradox has obvious implications for energy science and combating climate change (not to mention traffic engineering), it applies to software development as well. The related Wirth’s Law holds that as hardware gets more efficient and thus faster, software can be proportionally less efficient and thus slower. This may explain why my laptop today feels about as fast as the one I owned ten years ago, despite having orders of magnitude more processing power.

This paradox seems important to keep in mind when managing teams as well. I recall one time at work where we realized that developers were spending quite a bit of time responding to information requests from the rest of the company about our product’s capabilities. So we decided to make this process more efficient on our end, first by introducing a rotation where each week one engineer would be responsible for fielding these questions, and eventually an entire team responsible for the task (among other things). As we were able to respond to these inquiries more quickly, their number only grew, perhaps because “ask an engineer” was now more efficient for our colleagues than “search Slack” or “reference past proposals”. A better approach might have been to phase in an alternative to engineers as a resource for answers, such as an internal knowledgebase populated over time by our previous answers to such questions.