Green Software Engineering!

Cloud Nord 2021 · France, Europe

by Asim Hussain · 5 December 2021

▶ talk tech green

This was an early outing for green software engineering at Cloud Nord 2021 — an emerging discipline that sits at the crossroads of climate science, software architecture, electricity markets and data-centre design. I lay out its two philosophies, walk through a taxonomy of three actions you can actually take, and explain the Software Carbon Intensity standard we were building at the Green Software Foundation.

AI-generated summary of my talk

Key takeaways

Green software is about reduction, not neutralisation. The goal is fewer physical carbon molecules in the atmosphere — you can’t be a green application by doing nothing and buying offsets.
Everybody has a part to play. The old approach only ever talked to the five people who pick the data centre. Whatever your discipline, there’s something for you to do.
Sustainability justifies itself. A green app is almost always cheaper, faster and more resilient — but if you only ever argue “it’s cheaper”, you win the battle and lose the war. The aim is to make sustainability a normal topic in every technical meeting.
Three actions: energy efficiency (use less electricity), hardware efficiency (use less hardware), and carbon awareness (do more when the grid is clean, less when it’s dirty).
Most on-premise servers run at roughly 10% utilisation. So raising utilisation beats micro-optimising your code — and making devices last longer cuts embodied carbon.
Electricity varies in cleanliness by region and by time — and sometimes there’s so much surplus wind that it’d otherwise be thrown away, which is the perfect, near-zero-carbon moment to run your work.
How you measure dictates where you invest. That’s why the SCI standard is consequential and growth-aware — a score, not an accounting total — built from the ground up to reward reduction.

Jump into the talk

What green software engineering even is

Green software engineering is an emerging discipline at the intersection of climate science, software practices and architecture, electricity markets, hardware, and data-centre design. To be a green software engineer you have to know a whole bunch of things you’re never normally taught: what electricity is, how it’s bought and sold, how hardware uses it to execute your software, how data centres are built and function. None of that is on the usual syllabus.

And we are hyper-focused on one thing: reduction. Green software is the discipline of building software that emits less carbon into the atmosphere — fewer physical carbon molecules, full stop. It is not neutralisation. You cannot be a green application solely by doing nothing and buying some offsets. Offsets matter enormously, but they’re not what this discipline is about.

Two philosophies

The first philosophy is that everybody has a part to play. I lean on an old Ogilvy report, Mainstream Green, which found that roughly 16% of an audience are “super greens” — fully aware and willing to act — and a chunk at the other end are “green rejecters”. For years we told the super greens to care, and then gave them nothing to do but go on a march. Meanwhile they’re sitting at their jobs eight hours a day, yearning for something concrete. We failed to provide it, because we only ever focused on the five people in an organisation who can pull the biggest lever — the ones who pick the data centre. The average engineer has no such influence. So green software engineering deliberately opens the door to everyone — front end, machine learning, databases, IT decision-makers, people just starting out. We try not even to use the word “engineer”, because so many people are involved in the business of building software.

The second philosophy is that sustainability is enough, all by itself, to justify the work. A green application is almost always cheaper, faster and more resilient than its grey counterpart. The temptation is to argue purely on those merits — “this is cheaper, let’s do it” — and never say the word sustainability. You win the battle that way, but you lose the war. The goal is to make sustainability a normal, everyday topic, discussed on balance with security, performance, cost and bug risk in every technical meeting.

The taxonomy of actions

Greening software broadly breaks into two kinds of action: making it carbon efficient (changing the code or architecture so it emits less) and making it carbon aware (changing its behaviour). That gives three concrete levers.

Energy efficiency — use less electricity to do the same job. Energy is the single biggest source of carbon, around 25% of global emissions, because most electricity is still generated by burning fossil fuels, mostly coal. Electricity is what we call a proxy for carbon: so tightly linked you might as well treat it as carbon. Use less, emit less.

Hardware efficiency — use less hardware to do the same job. Everything emits carbon when it’s created and when it’s destroyed; that’s embodied carbon, the carbon baked into a physical thing. Here’s the counter-intuitive bit: the first place people go is code efficiency, but most on-premise servers sit at roughly 10% utilisation. Making your code leaner often just leaves the server 5% utilised instead. The real win in the cloud is raising average server utilisation — run more on each box, pin it towards 100%. Yes, servers run hot are more likely to fail, but the benefit far outweighs that. From a device’s angle, the lever is longevity: most hardware doesn’t break, it just reaches end of life when the software won’t run on it anymore. I had to retire an old iPhone I’d given my mother purely because Skype stopped working on it. Efficient software runs on older hardware, which means it lasts longer, which amortises its embodied carbon over more years.

Carbon awareness

Electricity varies in how clean or dirty it is — its carbon intensity, measured in grams of carbon per kilowatt-hour. The global average in 2019 was 519 grams; picture half a kilo of soot in your hands. It varies by region, depending on how much renewable generation a grid has, and — more surprisingly — by time. Grids have almost no storage, because batteries are wildly expensive, so utilities must match supply to demand every single minute. When the wind drops or the sun goes in, they burn more coal or gas to fill the gap, and carbon intensity climbs. Occasionally the opposite happens: so much wind is generated that there’s nowhere to put it, and it gets thrown away. Use electricity in that moment and you’re effectively running at zero grams of carbon. Carbon awareness is simply building software that understands this and takes advantage of it — doing more when renewables are plentiful, less when they’re scarce. Tools like WattTime and Electricity Map expose this data across the world’s grids.

Why teams don’t act, and the SCI standard

Here’s the problem: there’s very little incentive for software teams to chase these three actions. Two reasons. First, neutralisation — it’s cheaper and less risky to buy an offset than to pay a team of developers to refactor risky code. Proper net zero means reducing first and only offsetting what you genuinely can’t reduce, but a lot of people hear “net zero” and just think “buy offsets”. Second, measurement dictates investment. If your green-ness number doesn’t move when you make the app more energy efficient, you’ll never invest in energy efficiency — and the same for hardware efficiency and carbon awareness.

That’s why at the Green Software Foundation we built the Software Carbon Intensity (SCI) standard. It’s a score for a software application, not an accounting total — and it’s engineered from the ground up so that doing any of those three actions makes the score go down. It differs from the GHG Protocol, the methodology every organisation uses for emissions reporting, in two key ways. It’s consequential, not attributional: we don’t care who “owns” a carbon molecule, only what reductions our actions make possible. That matters because organisational boundaries break down with software — Windows runs on over a billion devices, so its real energy footprint dwarfs what shows up in Microsoft’s books, and open-source projects like TensorFlow have no single organisation at all. And SCI is growth-aware. If your app’s emissions go from 34 tons to 82 tons in a quarter, is that bad? Not if you grew four times and took market share from a less efficient competitor. The GHG Protocol can’t see that; an intensity — carbon per API call, say, 3.3 grams down to 2.9 — can. The calculation itself is simple: energy times carbon intensity, plus embodied carbon, divided by a functional unit like users or API calls.

I take the open-measurement argument much further in Doing for Sustainability what Open Source did for Software.