Sustainable Software Engineering, Building Carbon-Efficient Applications

GOTO 2020 · Europe

by Asim Hussain · 16 November 2020

▶ talk tech green

Sustainable Software Engineering, Building Carbon-Efficient Applications

This is my GOTO 2020 talk introducing sustainable software engineering — the discipline I helped codify at principles.green. It starts, embarrassingly, with cloth nappies, and ends with how to pick a greener moment to run your overnight batch jobs. In between I lay out the first three principles every engineer can act on.

AI-generated summary of my talk

Key takeaways

It started with poo. I was happy to deal with cloth nappies eight times a day for the environment, yet I’d never once raised my hand in an architecture meeting to ask for the greener option. That hypocrisy started the whole journey.
Two philosophies. Everyone across every computing domain has a part to play — not just a thin sliver of “high-impact” engineers — and sustainability is now reason enough on its own. Cheaper, faster, more resilient apps are bonuses, not the reason.
Principle one: carbon. Normalise every greenhouse gas to CO2-equivalent (methane is 20–80x worse), accept that everything emits, then always pick the most carbon-efficient option — the most user value per gram.
The car worked example. A petrol car is about 8% efficient at turning crude oil into forward motion; an EV on solar is roughly 60–70%. EVs are green because they’re efficient — that’s the whole game.
Principle two: electricity. It feels clean — no exhaust on your laptop — but most of it still comes from burning fossil fuels. Get literate: joules, watts, kilowatt-hours. Wind and solar dwarf what we actually need.
Principle three: carbon intensity. Grams of CO2 per kilowatt-hour varies by region and by the minute. Use Electricity Map, the UK’s free API or WattTime to shift workloads to greener regions or cleaner moments.
Embodied carbon and energy proportionality. Make hardware last longer, and keep machines well utilised — an idle server still burns a lot of power.

Jump into the talk

It started with poo

Just before my son was born, a friend gave me good advice: take the nappy changes, because that’s your quiet time with him. Then my wife decided we’d use cloth nappies, not disposables — for environmental reasons. So I got very, very used to dealing with poo, eight times a day. (I’m happy to talk about poo for hours; it gets everywhere — I’ve turned up to meetings with it on my face.)

A few months in, the penny dropped. How come I was willing to deal with poo eight times a day for the environment, yet I had never once — in any architecture meeting, any scrum, any design review — raised my hand and asked, “what’s the greener option?” I’d do it at home but never at work. That hypocrisy started the whole journey.

Building principles.green

I started by reaching out to a friend in the UK who’s both in tech and a member of the Green Party. He pointed me to ClimateAction.tech — still, I believe, the largest community of tech people passionate about the climate crisis. You can ask a detailed question in there and get a thorough, methodical answer within minutes. They pointed me at academic papers, and I spent a good six months reading long, dry, very domain-specific research.

I learned a lot — but I also realised I couldn’t expect the next person to repeat that slog. The knowledge needed to be condensed and structured into an accessible form. That’s what we launched as principles.green — the principles of sustainable software engineering. I didn’t coin the term; it came out of a Mozilla Foundation meeting and I latched onto it. To be a sustainable software engineer you have to broaden your knowledge: code runs on a computer, the computer uses electricity, electricity is bought and sold, and you’re building for users whose behaviour and psychology matter. The principles give you that breadth quickly, and breadth is what lets you see the solutions.

The two philosophies

First: everyone is part of this. I showed an Ogilvy advertising report from 2010, “Mainstream Green” — I trust an ad agency’s audience numbers because they’ll sell to anyone. It found roughly 16% of people identify as “super greens”, and a decade on I’d bet things have only polarised further. Super greens are our audience, but they’re spread thinly across every domain in computing, from designing user interfaces to designing silicon. Where we failed in the past was only ever talking to a thin sliver of “high-impact” engineers. The philosophy here is that there’s something for everyone, wherever you are.

Second: sustainability is enough. People who’ve been in this space for decades describe a sea change. It used to be that to talk about sustainability you had to wrap it in a different pill — call it cost reduction, call it performance. Sustainable apps usually are cheaper, faster and more resilient — but those are bonuses. The reason you do it is sustainability itself.

Principle one: carbon

“Green” means different things to different people, so we anchor on carbon. Greenhouse gases are a natural blanket warming the planet — that’s not in dispute; the problem is speed. Naturally these cycles play out over geological timescales that give forests time to migrate. Human activity is doing it in an eye-blink, too fast for plants, animals and us to adapt. There are several greenhouse gases — methane has 20 to 80 times the warming effect of carbon dioxide — so we normalise everything to carbon dioxide equivalent, which we shorten to “carbon”.

The goal is efficiency. No engineer is proud of being wasteful. My worked example is the petrol car versus the EV. Take crude out of the ground and turn it into petrol and you lose about half the energy potential; getting it to your car loses roughly another 20%; and an internal combustion engine is only about 20% efficient at turning petrol into forward motion. Net result: around 8% efficient. Nobody should be proud of building something 8% efficient — we only tolerated it because oil was cheap and plentiful. An EV running on solar (which I count as 100% efficient, since those rays were free and hitting the ground anyway), with very low transmission losses, ends up around 60–70% efficient. That’s why EVs are green: they’re efficient. So principle one is to build carbon-efficient applications — the most user value per gram of carbon emitted.

Principle two: electricity

I used to think electricity was clean — no smell, no exhaust pipe on your laptop. In fact it’s one of the dirtiest things going, because most of it still comes from burning fossil fuels, mainly coal. Electricity and heat generation account for around half of all greenhouse-gas pollution. I’d built an entire career depending on electricity without really understanding it, so part of being a sustainable software engineer is literacy: a joule is a unit of energy, a watt is one joule per second, a kilowatt is a thousand of those, and a kilowatt-hour is that flow run for an hour. You’ll hear kilowatt-hours constantly when measuring software and hardware.

That sounds depressing, but electricity is also the solution. Total worldwide energy consumption is about 18 terawatts. Capture every gust of wind on the planet and you’d have around a thousand terawatts. Solar is the staggering one — on the order of 178,000 terawatts, thousands of times more than we use. The technology already exists; we just have to make decisions. So principle two is to build energy-efficient applications — and not only for battery-powered devices, but for everything, including servers plugged into data centres. (Look up energy proportionality on principles.green — it’s a fascinating one.)

Principle three: carbon intensity

I picked this up from the Energy Transition Show podcast. Not all electricity is born equal: some comes from coal, some from renewables. The measure of how clean it is is carbon intensity — grams of CO2 per kilowatt-hour. The global average a year ago was 519 grams — picture half a kilo of ash in your hand for every kilowatt-hour. France is usually very low thanks to nuclear, as are Sweden, Denmark and Norway; the UK is fairly low; Germany sat around 185 when I checked; India, Australia and the eastern US run dirty.

It varies over time too, because wind and solar are variable. Our grid has very little storage — when you switch on your washing machine, the utility burns more gas or coal in real time to match it. So when the wind drops, intensity spikes; when it’s blowing and the sun’s out, intensity can fall to near zero. That opens up real choices. Got a machine-learning job that runs for days? Run it hardest at the cleanest moments. Got a continuous workload with no latency constraint? Site it in a greener region. I used to set arbitrary times for my cron jobs — but if it just needs to finish by 8am, why not pick the lowest-intensity moment dynamically? The UK has a free carbon-intensity API (no key, no registration, backed by universities); WattTime, a US non-profit, has better data for American grids; Electricity Map, based in France, is strong on Europe. So principle three: consume electricity with the lowest carbon intensity you can.

Embodied carbon, energy proportionality, and what’s next

Everything we make emits carbon in its creation — quite a lot of it. I’ll probably never offset the carbon embodied in making my phone, no matter how clean my electricity, because phones are so energy-efficient in use. The engineer’s lever here is simple: make hardware last longer. We replace things every three years largely because software keeps pushing the limits until nothing runs well — and that’s our fault, so it’s ours to fix.

Energy proportionality is the last idea: the more you use a device, the more efficiently it converts electricity into useful work. An idle server still draws a lot of power. It’s like a car at two miles an hour being less fuel-efficient than at fifty — there’s an optimum, and you want hardware running near it. There are more principles on principles.green — networking, demand shaping, measurement and optimisation. At Microsoft we’d just begun publishing guidance (how to run Kubernetes more sustainably, for instance) and launched a cross-company blog spanning hardware, energy, Windows and cloud. Very early, very nascent — all of us still figuring it out.