Pushing Sustainability Further with Green Software

Intel 2023 · United States

by Asim Hussain · 30 January 2023

▶ talk green

Pushing Sustainability Further with Green Software

I sat down with Camille Morhardt for her “What That Means” series to explain, in plain English, what green software actually is — how a “digital thing contained inside a box” ends up emitting carbon, and the handful of levers we have to bring that down. It wandered through electricity, dead phones, server utilisation and what utopia looks like. Here’s the map.

AI-generated summary of my talk

Key takeaways

Green software takes responsibility for its own emissions. Not building apps that make the world greener — that’s a separate thing — but software that minimises or eliminates the carbon it is itself responsible for.
Energy is a proxy for carbon. About 80% of the world’s electricity is still made by burning coal, much of it dirty coal we switched to after the cleaner sort was found to cause acid rain. Draw a straight line from energy to emissions, so using less energy means emitting less carbon.
Hardware efficiency is about embodied carbon. Every device emits carbon when it’s made and disposed of. My own phone was perfectly fine at three years old — I only upgraded because the software I needed stopped supporting it. That’s software-driven obsolescence.
Higher utilisation is greener, thanks to energy proportionality. A server at 0% utilisation isn’t using 0% energy; the more you load it, the more efficiently it turns electricity into useful work. One server at 100% beats ten at 10%.
Carbon awareness is using the right energy, not less energy. Do more work when the grid is clean, less when it’s dirty — often the easiest place to start, because it’s a question of when and where you run things, not a rearchitecture.
The field grew on a hockey stick. ClimateAction.Tech went from a couple of hundred people to several thousand; the Green Software Foundation launched with eight members and is now around 37.
The goal is guilt-free consumption — zero harmful environmental effects from using software, so users never have to make a choice in the first place.

Jump into the talk

What green software actually means

There are a few ways to think about being green with software. One is building software that makes the world more sustainable — software that does farming in a more environmentally good way, say. The other, the one I care about, is acknowledging that software is itself an emitter of carbon and asking how you reduce the emissions it’s responsible for. That’s how we define green software: software that takes responsibility for its own emissions and tries to minimise or eliminate as much of them as possible.

Camille asked the obvious, fair question — software is a digital thing inside a box, it doesn’t fart or puff, so how is it emitting anything? The answer is that software is a driver of emissions. We talk about four principles, and the first is carbon efficiency: emit the least carbon possible. It sounds obvious, but obvious statements sometimes need making — three years ago there was genuinely a lot of argument about it. And there are really only three levers underneath it.

Energy and hardware efficiency

The first lever is energy efficiency, and electricity is where my own journey took a humbling turn. I’d been in software for two decades and never really knew what electricity was — how it’s made, bought, sold, how it differs country to country. It might as well have been magic coming out of a wall socket. But electricity is the single biggest source of carbon emissions in the world, and around 80% of it is still made by burning coal — often very dirty coal, because 20 years ago we discovered the cleaner sort caused acid rain and flipped to the dirtier sort. So we call energy a proxy for carbon: there’s a straight line between the two, and using less energy means emitting less.

The catch is incentives. Phones are pushed hard to be energy efficient because nobody wants a battery that dies in a minute. But software running on machines plugged into a socket with effectively infinite energy gets almost no such pressure — in the cloud, none of the energy cost is even passed through to you; consume a lot or a little, you pay the same.

The second lever is hardware efficiency, which is about embodied (or embedded) carbon — the carbon emitted when a device is manufactured and, later, disposed of. As a software person, what do you do with that? For end-user devices it’s mostly about extending the usable lifespan. I held up my old phone in the conversation: nothing wrong with it, only three years old, never broke — I was forced to upgrade simply because the software I needed stopped working on it. That’s software-driven obsolescence, and writing software that keeps running on older hardware is a direct lever against it. It’s a flavour of the right-to-repair argument, but for software.

Utilisation and carbon awareness

In the cloud, hardware efficiency mostly means increasing server utilisation. Most servers sit at low utilisation for all sorts of architectural reasons, and that trade-off can usually be rebalanced. Camille pushed back — surely running less saves energy? Not quite. Two servers at 50% do the same work as one at 100%, but the one server emits less once you fold in both energy and embodied carbon. And there’s a second effect: energy proportionality. A server at 0% utilisation isn’t drawing 0% energy, and once you’re up around 60–70%, getting to 100% barely costs more. The more you use it, the more efficiently it turns electricity into useful operations.

The third lever is carbon awareness, which someone framed beautifully: energy efficiency is about using less energy, carbon awareness is about using the right energy. Build software that does more when the grid is clean and less when it’s dirty. I’m in the UK, which has a decent amount of wind — it’s been stormy lately and a lot of our electricity has come from it. If your software can lean into those clean windows and ease off when the wind drops and the sun isn’t shining, you cut emissions. There’s huge interest in it right now, partly because it’s one of the easiest ways in: it’s a decision about when and where you run things, not a full rearchitecture.

A field on a hockey stick

This has moved fast. About three and a half years ago I was managing a team at Microsoft, doing everything more sustainably at home but with no idea how to do my actual job — the thing I spend most of my waking hours on — more sustainably. So I started exploring, and joined a community called ClimateAction.Tech, which I’d recommend to anyone looking for like-minded people. It was a couple of hundred people then; it’s several thousand now. Around the time the Biden administration came in, something shifted — organisations that had ignored the topic suddenly all got in touch at once. But you can’t have those conversations bilaterally with 20 companies, which is exactly why something like the Green Software Foundation had to exist. We launched with eight members; we’re now around 37, with hundreds of people involved.

Why the shift? I can only guess, but the youth movement is clearly part of it. Several execs have told me, off the record, that they’re engaging because their kids are asking them questions at the dinner table. There’s a report called Mainstream Green that found roughly 18% of people are what they’d call “super green” — already present in every organisation and every role. The underlying desire was there; something just raised it up everyone’s radar.

Where to start, and what utopia looks like

I used to think this would all be a checklist — naive. It turned out to be an entire field of computing, and the right advice for a machine-learning engineer can be the exact opposite of the right advice for a web developer, so a lot of it has to get into your specific stack. The best people to green your software are your existing teams; what they need is to understand the levers. So the Foundation built resources around that: principles.green (the eight principles), a roughly three-hour certification to level-set experienced practitioners, role-specific catalogues for web, cloud and machine learning, and — the hardest problem of all — a specification for measuring software. There’s also a carbon-aware SDK, an open-source library that abstracts over the various data providers so you can simply ask it where and when to run a workload without rewriting your software each time you change provider.

And utopia? The outcome we want is zero harmful environmental effects from using software — not just carbon, but air quality and water scarcity too. It feeds my own philosophy: I fly, I offset, and I don’t feel guilty, because the future I want isn’t one where people agonise over every choice. It’s guilt-free consumption — you shouldn’t have to ask whether you really need to watch TV at this resolution, because we’ve solved the problem on the other side. It isn’t something you “win”. It’s something some of us work on from now to eternity, counterbalancing the other forces, until the balance is one we can all live with.