What is the carbon score of your software?
Thoughtworks 2022 · Online
by Asim Hussain · 28 July 2022
I walked Thoughtworks through the foundations of green software — what “green” actually means, the three things you can do about it, and then the bit no one wants but everyone needs: an equation that gives your software a carbon score. I close on the Software Carbon Intensity spec and the certifications we were launching at COP27.
AI-generated summary of my talk
Jump into the talk
- 0:06 What does 'green' even mean?
- 2:06 Energy efficiency and energy proportionality
- 9:12 Carbon awareness and the carbon intensity of electricity
- 18:17 Carbon-aware computing in the wild
- 20:22 Hardware efficiency and embodied carbon
- 25:23 Measuring: the GHG Protocol and why totals fail
- 29:28 A rate, not a total — the SCI specification
- 32:30 Abatement only, net zero, and COP27
What “green” actually means
When we started in this space there were lots of competing definitions of “green”. Right now we focus squarely on carbon emissions — that may broaden to other environmental targets over the years, but carbon is the target today. Greenhouse gases sit in the atmosphere acting like a blanket, warming the planet, and the warming is roughly a function of how much carbon is up there. So the goal is simply to put less carbon in.
A note on language: when I say “carbon”, I mean all greenhouse gases. There are loads of them — methane has something like a 40-to-100-times warming effect depending on where it is in its life cycle — but we normalise everything into carbon dioxide equivalent. A tonne of methane becomes roughly 40 tonnes of CO2e. So one number does all the work.
From there, everything stems from carbon efficiency: emit the least carbon possible. That’s the first principle. When you have a choice and one option emits less than the other, take it — that’s good enough. There are then only three things you can do to make an application greener: energy efficiency, hardware efficiency, and carbon awareness.
Energy efficiency — and the idle-server trap
When I first got into this I knew nothing about electricity, which now feels absurd given my whole world revolves around it. You plug something into the wall, there’s no smell, no exhaust pipe, so you assume it’s clean. It isn’t. Generating electricity is the single biggest emitter of carbon into our atmosphere, because most of it still comes from burning fossil fuels — and often the dirtiest coal, since the higher-quality coal causes acid rain.
So if electricity is tied to carbon, being energy efficient is being carbon efficient. The surprising part is energy proportionality. I’d assumed an idle laptop drew near-zero watts and ramped up linearly. It doesn’t. Every core draws static power whether you use it or not, and the more you load a machine, the better it gets at turning electricity into useful work. The upshot: an idle server still consumes a serious amount of electricity, and the global average for on-premise server utilisation hovers around 10%. That’s 90% idle — a colossal amount of waste.
Which is why you should pin servers to 100% utilisation. I put that exact question to people running very high-performance computing at Microsoft — won’t the failure rate climb? Their answer: pin it to 100, because you’ll never actually get there, and besides, the failure rate rises a little but it’s better overall. And this reframes “green” entirely. It isn’t the worse, naff option — green means a lack of waste, and you have to be a very good engineer to eliminate it.
Carbon awareness — electricity varies by place and time
Electricity isn’t just dirty; its dirtiness varies. The measure is carbon intensity — grams of CO2 per kilowatt hour. The pre-Covid 2019 global average was around 519 grams per kWh. Picture half a kilo of soot ash in your hands for every kWh — and my electric car has a 64 kWh battery, so that’s a lot of ash if it were all coal.
It varies by location. France is extremely low because most of its grid is nuclear, which is very low-carbon. Norway is brilliant thanks to all that hydro. Parts of the US east coast can be far higher. So simply running your work in a cleaner region cuts emissions.
It also varies by time, and this is where it gets interesting. Our grids were built on the idea that if you want more power, you burn more coal or gas — think of coal as a chemical battery — so there’s almost no buffer; when you switch on a kettle, someone generates more electricity that instant. Add wind and solar and you get real variability: clouds roll in and the clean power vanishes, gas spins up fast to fill the gap, and intensity climbs. The flip side is that sometimes there’s so much wind that clean energy gets thrown away, because coal and gas plants can’t drop to zero — they take days to spin back up. Those moments are effectively zero-carbon electricity, and they’re the perfect time to run things, because your money flows to renewable plants and helps accelerate the energy transition.
Carbon-aware computing in the wild
That’s the idea behind carbon-aware computing: do more when intensity is low and less when it’s high. Microsoft shipped a Windows feature that schedules updates toward lower-intensity periods. Google did terrific work on carbon-aware data centres, flexing very homogeneous workloads to run when the grid is cleaner — their reports put the initial saving at around 1% of Google’s emissions, which sounds small but is an enormous amount of effort in this space. The Foundation is building a Carbon Aware SDK to make this easier, with Thoughtworkers among the contributors. The appeal is that you don’t re-architect anything — it’s just a choice of when and how you scale. Low investment, modest upside: you won’t get 100% reductions this way, but tapping roughly 10% for very little effort is a good first dip into green computing.
Hardware efficiency and embodied carbon
Everything emits carbon when it’s built and when it’s responsibly decommissioned. That’s embodied carbon, and it can be very significant. The strategy differs by device. A modern phone is already astonishingly energy efficient — the platforms won’t let you ship a battery-draining app — so most of its lifetime carbon is already emitted before you switch it on. There the goal is longevity: don’t force people to upgrade because your inefficient software made a perfectly good device obsolete. That’s a software story, not a hardware one. Servers are the opposite end: pinned near 100%, most of their lifetime emissions come from energy, so the play is utilisation — why run five servers at 20% when one at 100% will do?
Measuring — and why totals are the wrong number
Now the part nobody enjoys: an equation. There are two routes. Fortune 500s mostly use the Greenhouse Gas Protocol, which sorts emissions into scopes — scope 1 (direct, like a diesel generator), scope 2 (the energy you buy), scope 3 (your supply and value chain). It’s genuinely confusing for software. Whether your app’s energy lands in scope 2 or scope 3 depends on whether you own the servers or rent the cloud; hybrid setups end up smeared across both. And it forces you to compute a total, which means knowing everywhere your software runs — impossible for open source, which makes up something like 90% of an enterprise stack.
Worse, the total doesn’t tell the story. Imagine you lead carbon reduction for a platform: Q1 you’re at 34 tonnes, Q2 it climbs to 52. Fired or promoted? Software is a growth space — if you’re staffed on a product, it’s almost certainly because it’s growing, so emissions grow with it. The useful number is a rate. If you went from 3.3 grams per user to 2.9 grams per user, that’s progress worth a bonus, regardless of how much the product grew.
A rate, not a total — and why you can’t buy your score
That rate is the Software Carbon Intensity specification. It ties everything together into one score: energy consumed multiplied by carbon intensity (the use-phase emissions), plus the embodied carbon of the hardware, all per R — a functional unit you choose to match how your app scales. For a video call it might be carbon per minute. Once it’s a rate it becomes comparable and targetable, and the only way to move it is the three levers: more energy efficient, cleaner electricity, less or better-used hardware.
The team made one deliberate choice: you can only improve the score through abatement — not putting carbon into the atmosphere in the first place. Not offsets. Offsets come in two flavours: neutralisation (removing carbon and storing it, like planting trees) and compensation (paying someone else not to emit). The SCI counts neither. You can’t pay your way to a better score; you can only engineer your way there. That matters because it maps cleanly onto a net-zero strategy, which has a precise meaning — by 2050 you abate 90% of emissions and may only neutralise the last 10%. Adopt the SCI, drive the score down, and you can be confident you’re moving toward net zero.
The SCI was in alpha at the time of this talk, due for release at COP27 that November, alongside the Green Software for Practitioners training and an SCI practitioner certification — so you could be certified both to think this way and to actually score an application against the spec.