Sustainable software engineering building carbon efficient applications
MTG France 2020 · France, Europe
by Asim Hussain · 27 October 2020
This is my early, foundational talk on sustainable software engineering — the one where I walk through the principles I’d just codified at principles.green. It’s a discipline most people had never heard of in 2020, so I start from first principles: what “carbon” even means, why efficiency is the only honest goal, and how electricity and hardware quietly become proxies for carbon you can actually measure.
AI-generated summary of my talk
Jump into the talk
- 0:08 The cloth-nappy epiphany
- 5:10 Why we wrote principles.green
- 7:10 Principle 1: define carbon, aim for efficiency
- 11:11 Petrol cars vs electric vehicles
- 14:14 Principle 2: electricity literacy
- 21:14 Principle 3: carbon intensity
- 27:20 Embodied carbon and the laptop heckler
- 33:28 Energy proportionality
- 37:31 Networking and demand shaping
- 41:33 Two philosophies: everyone, and carbon is enough
The epiphany that started it
I open with my son, Micah. Before he was born a friend gave me advice — take the nappy changes, because your wife gets the quality time breastfeeding and you’ll want yours too. So I did. Then my wife decided we’d use cloth nappies rather than disposables, and if you’ve never met a modern cloth nappy, they’re surprisingly advanced — elastic, bamboo inserts — but you deal with a lot of poop. He pooped eight times a day, and I got completely unbothered by it.
A few months in I had the epiphany. I was happy to deal with poop eight times a day for the environment, yet I’d never once — in any scrum, any architecture discussion, any technical meeting in my whole career — raised my hand and asked, “What’s the greener solution?” That gap sent me on a long journey, which eventually became my full-time job at Microsoft: figuring out how to build green applications in the cloud, and even what a “green application” means, because it turns out not everybody agrees.
Why we wrote principles.green
I asked around, and a friend in the Green Party pointed me at a community called Climate Action Tech — a Slack group, a few thousand people, experts in pretty much any area, and I’m now a co-organiser. I learned a huge amount there, but most of it lived scattered across academic papers and books. What we needed was to condense it into a core set of principles — because this isn’t about me telling you the right decision, it depends entirely on what you’re building. Give people the underlying knowledge and they can make the right call themselves.
That became the eight principles at principles.green. I didn’t coin the name “sustainable software engineering” — I believe that came out of meetings at the Mozilla Foundation — but I’d argue I was the first to get it all down into one structured, easy-to-understand place.
Carbon, and why efficiency is the only honest goal
The first problem was language: “green” means different things to different people, so principle one is to get aligned on what we’re actually optimising for. By carbon I mean greenhouse gases — the blanket warming the planet. The greenhouse effect is entirely natural; the problem is the speed. Human activity has shot the concentration up too fast for animals, cities or billions of people to adapt. There are many greenhouse gases — methane warms 20-80 times harder than CO2 — so we normalise everything into carbon dioxide equivalent and just call it “carbon”.
My position is that we’re always going to emit carbon — I breathe, I emit carbon. So the goal might be zero, but the direction we face is carbon efficiency: for every gram we emit, get the most user value possible. My favourite illustration is the car. A petrol car loses about 50% of the energy just refining crude into petrol, another ~20% shipping its weight around, and the engine is only ~20% efficient at turning fuel into motion — landing at around 8%. Nobody should be proud of 8%. An electric vehicle, fed from solar we treat as 100% (the sunlight was hitting the Earth anyway), loses very little getting electricity to the car and is 60-70% efficient at turning it into motion. Green is just efficiency. Show me a developer who doesn’t care about efficiency and that’s a developer I’d never want to hire.
Electricity, and learning to read it
I used to think of electricity as clean — no smell, no dirty hands. The reality is it’s one of the dirtiest things on the planet, because roughly 80% of the world’s electricity is still made by burning fossil fuels, mainly coal, and it’s responsible for a little under half of all carbon pollution. France is a happy exception, largely on nuclear. So principle two is to build energy-efficient applications — and I genuinely believe electricity should be literacy, taught as module one of any computer science degree. How did I reach an advanced stage of my career without understanding the thing that fuels all my computing?
The vocabulary you need: a joule is a volume of energy, a watt is one joule per second (a flow), a kilowatt is a thousand joules per second, and a kilowatt-hour is the volume you’d get leaving a kilowatt running for an hour. Don’t despair, though — electricity is also the solution. The world consumes about 18 terawatts; there’s roughly 1,000 terawatts available from wind and 173,000 from solar. We have on the order of 10,000 times more energy available via solar than we currently use. Electrify everything.
Then comes carbon intensity — the idea that not all electricity is born the same way, measured in grams of CO2 per kilowatt-hour. The 2019 global average was 519 grams per kWh; France regularly runs under 100, while some places sit above 1,000. It varies by region (some grids have more renewables) and over time (when the wind drops, utilities burn more coal and gas to match demand, so intensity rises). That means you can pick a cleaner region, or go real-time: Electricity Map from Tomorrow lets you hover over grids worldwide, the UK has a completely free carbon-intensity API with no login, and WattTime tends to have the best US data. Draw a line from any resource to carbon and that resource becomes a proxy you can be efficient with.
Embodied carbon — and the laptop heckler
My favourite anecdote: after a talk in Poland, a man queued patiently, told me he loved my presentation style, then said “but you used a laptop, so I can’t believe anything you said” — and walked off. He sat through the whole thing, angry, just to deliver that. It’s a daft “what about” argument, but he was describing something real: embodied carbon, the emissions baked into making a thing. Everything releases carbon when it’s manufactured — these headphones, a laptop, a server — and there’s a whole field measuring it.
The way to think about it is to amortise. A server might embody around four tonnes; spread over a four-year life that’s roughly a tonne a year, a continuous cost rather than a sunk one. The Dell R640 publishes about 1.2 tonnes embodied — across four years that’s 320 kg a year, and against a fairly clean European energy mix the annual total works out around 800 kg, so embodied carbon is roughly 40% of it. That’s enormous: you could make your software maximally energy-efficient and it’s still emitting, because the hardware already emitted. So what can software do? Make hardware last longer. Stretch a four-year lifespan to five and you knock the annual embodied figure down by about 9%. At Microsoft we don’t throw servers away — we’re building circularity centres to break them down for spare parts. Hardware is a proxy for carbon, so be hardware-efficient: reuse it, recycle it, and write applications that keep older devices useful.
Energy proportionality, networking and demand shaping
Energy proportionality is the counterintuitive one: the more you use hardware, the more efficient it gets at turning electricity into useful work. Even at 0% utilisation a server still draws power — say 100 watts — because network cards, memory, spinning disks and a static per-core CPU draw all consume regardless. So two servers at half-utilisation might burn 360 watts where one server doing the same work burns 200. The average private data centre — not hyperscale clouds like Microsoft’s — runs at just 10-15% utilisation, which breaks both this principle and embodied carbon at once. Hence: maximise the energy efficiency of hardware, largely by utilising it more.
Networking is just more computers, so it has its own electricity and embodied costs; the two big levers are the amount of data and the distance it travels. More data emits more carbon, and the same data over a longer distance emits more — so use edge nodes and CDNs, build less chatty applications, do more on the database side and send skinnier payloads. Finally, demand shaping: when a resource is constrained, don’t grab more — demand less. Video-conferencing software already does this, dropping resolution or switching to audio-only when bandwidth falls. We should do the same for carbon: a mobile network is many times more carbon-inefficient than wi-fi, so a carbon-aware application might offer an eco mode or nudge a video call to voice when carbon is expensive. That’s squarely a job for designers, not just engineers.
Two philosophies to close on
I end on the two ideas that hold the whole thing together. First, everyone has a part to play — frontend, backend, UX, product. This isn’t a niche for database specialists who “cost the most carbon”; there’s something for whoever you are. Second, carbon is enough. We used to wrap sustainability in sweeteners — it’s cheaper, it’s faster, it’s more resilient — because we were almost embarrassed to say we were doing it to be green. That’s changed. Yes, green applications usually are cheaper, faster and more resilient, and those make useful arguments — but they’re added advantages, not the reason. The primary reason is sustainability, full stop. You can find all eight principles at principles.green.