Eroom’s Law and the Future of Sustainable Software Development by Benjamin Schwartz

This blog draws inspiration from a recent episode of the Green IO podcast, in which Tristan Nitot discussed erooM’s law with host Gaël Duez. Eroom challenges our current approach to software and hardware. Listening to this conversation, I couldn’t help but reflect on my journey as a developer and the potential of erooM’s law to reshape how we think about digital sustainability.

From the code of the past to the challenges of today

I wrote my first code on an Amstrad in the 80s and became a developer when the industry was still defining itself. By the 90s, I was deep into C++, with Sun workstations as the ultimate dream machines. As my career progressed, I (regrettably) moved from coding to management just as Java became the “sexy” new language. I’m no longer an active developer, but my early experiences gave me a front-row seat to the priorities that shaped our industry.

When I joined the industry, there were no retirees. My first teachers and mentors, who had used punchcards, still considered compute time the most critical resource. They regarded the relatively new BIOS as the pinnacle of abstraction.

Yet Moore’s law was unstoppable. Most programmers (that’s what we were back then) gradually realised that the tacit partnership between Microsoft and Intel, the “WinTel monopoly” described but not named in the podcast, was a cartel. We became a much more critical resource than computers, and like most, my annual pay rise was double-digit for most of my decade as a programmer.

So, software development was expensive, and our time had to be maximised for impact.

To do that, we leaned heavily into abstraction to cope with the growing complexity of our projects and, even more, to minimise developer effort and maximise code reuse. We condescendingly thought that most of what came before us was spaghetti code. Complex architectures became the norm, with layers upon layers designed to make code more reusable and systems more maintainable. While this approach aimed to save time and human resources, it came at the cost of computational efficiency. Fortunately, Moore’s law allowed us to overlook this trade-off for decades, as hardware improvements compensated for software inefficiencies.

erooM’s law: A paradigm shift

ErooM’s law, as Tristan Nitot described it in the podcast, flips Moore’s law on its head. It argues that instead of relying on endless hardware upgrades to offset bloated software, we should optimise software to extend the life of existing hardware. This law is more than sound engineering; it is necessary in a world where manufacturing hardware seems to have a more significant environmental impact than using it.

Tristan shared striking examples of inefficient code, including cases where optimisation improved performance hundreds of millions of times. These examples underscore the extent to which latent inefficiency exists in modern software, a direct result of prioritising developer productivity over computational efficiency.

AI and the Future of Development

AI detractors don’t seem to have a game plan, and its exponential growth could once again shift the balance of priorities. AI tools promise to drastically boost developer productivity, enabling rapid code generation and optimisation. This trend could reduce the need for highly reusable, abstracted architectures designed to save developer time.

We could return to simpler practices, where AI-assisted developers focus on writing lean, hardware-optimized single-use code tailored to specific tasks. AI handles much of the repetitive grunt work, abandoning complex architectures born out of an obsolete necessity.

This shift would require intentionality so that AI doesn’t perpetuate the inefficiencies of abstraction.

Rebuilding for sustainability

Tristan’s vision for erooM’s law offers a robust roadmap for rethinking software. After listening to the excellent podcast, I think that to create truly sustainable systems, we need to:

• Prioritise lean, efficient code that runs closer to the hardware.
• Rebuild open-source projects with efficiency as a core design principle, even if that means sacrificing reusability, which AI can compensate for.
• Move away from over-reliance on abstraction layers that inflate computational costs.
• Accept that “write once, run many” will probably no longer be the best goal, and some target platforms will require a dedicated code base with much less reuse than we’ve become accustomed to.

The software industry once took great pride in its innovations, such as containers and, before that, emulators. These tools may eventually be seen as symbols of a bygone era's wastefulness. However, development productivity can reduce software's energy footprint by shedding unnecessary layers and using leaner architectures.

A call to action

Listening to Tristan and Gaël also felt like a call to action. ErooM’s law challenges the industry to stop relying on hardware upgrades to solve problems that could be addressed by more innovative software. It calls on technologists to revisit the principles that guided much earlier programming —efficiency, resourcefulness, and a deep understanding of hardware— and apply them in a modern context.

A case in point is modern PC games, which typically require tens of gigabytes because it's easier for developers to put everything, including multiple copies of the same texture, into a single monolithic bundle. When cartridges were used, resource optimisation was critical.

As someone who thrived in an era when developer time was the scarcest resource, I now see the urgency of valuing computational efficiency as equally, if not more important. Back to the future! As half a century ago, the industry must embrace optimisation as a moral imperative to address the environmental impact of our work, perhaps including a move back to bare-metal approaches.

TL;DR: I loved the podcast and agree that by aligning with erooM’s law, we can write a new chapter in software development—one in which innovation and sustainability are integrated—and I feel good to have gotten the abstraction layer part off my chest.