Climate-Friendly Software: Don't Fight the Wrong Battle

When talking about software ecodesign, green IT, climate-friendly software, the carbon footprint of software, or however you name it, most of the time people focus on energy efficiency and server-side code, sometimes going to great length measuring and monitoring it. But what if all this was misguided?

Ok, this is a bit of a bold statement, but don't get me wrong: I'm not saying you shouldn't care about this. Let's look at one of the most recent examples I've seen: GitHub's ReadME Project Q&A: Slash your code's carbon footprint newsletter issue. It's good and I agree with many things in there (go read it if you haven't already), but it talks almost exclusively about energy efficiency and server-side code, or in other words it limits actions to the scope 2 of the GHG Protocol.

So let's first understand which impacts we're talking about before I give you my opinion on the low-hanging fruits.

Disclaimer: people regarded as experts in green IT trusted me enough to have me contribute to a book on the subject, but I'm not myself an expert in the field.

Note: this post is written for developers and software architects; there are other actions to lower the climate impact of the digital world that won't be covered here.

Stepping back

Most software nowadays is client-server: whether web-based or mobile, more and more end-user software talk to servers. This means there's a huge asymmetry in usage - even for small-scale professional software the end users generally vastly outnumber the servers. And this implies the impacts of the individual clients need to be much lower than those of the servers.

What life-cycle assessments (LCA) for end-users' devices tell us is that manufacturing, transport and disposal summed up immensely outweighs use, ranging from 65% up to nearly 98% of the global warming potential (GWP). Of course, this depends where the device was manufactured and where it's being used, with the use location's biggest impact being related to the carbon footprint of the electric system, as the use phase is all about charging or powering our smartphones, laptops and desktops.

I am French, working mainly for French companies with most of their users in France, so I'm ready to admit I'm biased towards a very low use phase weight compared to other regions: go explore data for your users on Electricity Map and Our World in Data. And yet, that doesn't change the fact that the use phase has a much lower carbon footprint than all three of manufacturing, transport, and disposal as a whole.

What we can infer from this, is that keeping our devices longer will increase the share of use in the whole life-cycle impacts. Fairphone measured that extending the lifespan of their phones from 3 to 5 years “helps reduce the yearly emissions on global warming by 31%, while a further extension to 7 years of use helps reduce the yearly impact by 44%.”

Extending the lifespan of a smartphone from 3 to 5 years can reduce its yearly global warming impacts by almost a third.

Things are different for servers though, where the use phase's share varies much more depending on use location: from 4% up to 85%! As noted in the ReadME Project Q&A linked above, big companies' datacenters are for the most part net-neutral in carbon emissions, so not only the geographic regions of your servers matter, but also the actual datacenters in those regions. This implies that whatever you do on the server side, its impact will likely be limited (remember what I was saying in the introduction?) Of course there are exceptions, and there will always be, so please look at this through the prism of your own workloads.

Keep in mind the orders of magnitude though: 70 kg CO₂e for a single Pixel 7 (on 3 years) vs. 7730 kg CO₂e for a Dell PowerEdge R640 server (on 4 years), that's 110 smartphones for a server (or a 83:1 ratio when considering yearly emissions): chances are that you'll have much more users than that. The ratio for laptops (304 kg CO₂e on 4 years for a Dell Precision 3520) would be 25 laptops for a server. But as seen previously the actual carbon footprint will vary a lot depending on the location; you can explore some data in the Boavizta data visualization tool that compiles dozens of LCAs of various manufacturers. The Dell PowerEdge R640 in France would actually emit 1701 kg CO₂e rather than 7730 kg CO₂e: that's a 4.5:1 ratio! Comparatively, my Dell Precision 3520 would fall from 304 kg CO₂e to 261 kg CO₂e, only a 1.16:1 ratio. The laptop to server ratio would thus fall from 25 down to 7.9:1, which makes the laptops' impacts comparatively much bigger than the server compared to other regions.

Note that there are three tiers: end-users, datacenters, and networks. Network energy consumption however doesn't vary proportionally to the amount of data transferred, which means we as users of those networks don't have much levers on their footprint. That being said, data transmission is among the things that will drain the batteries of mobile devices, so reducing the amount of data you exchange on the network could have a more direct impact on the battery life of end-users' smartphones (even though what will drain the battery the most will more likely be the screen).

Taking action

So, what have we learned so far?

• It's important that end users keep their devices longer,
• we can't do much about networks,
• the location (geographic region and datacenter) of servers matter a lot, more so than how and how much we use them.

Now, what can we do about it?

For servers, it's relatively simple: if you can, rent servers in energy efficient datacenters, and/or countries with low-carbon electricity; in addition, or otherwise, then of course optimise your server-side architecture and code. If you manage your own servers, avoid buying machines to let them sit idle: maximise their utilisation.

Pick servers in carbon-neutral or low-carbon datacentres first, then optimise your architecture and code.

For the networks, our actions are probably limited to reducing data usage, “not because it reduces immediate emissions (it doesn't), but to avoid the need for rapid expansion of the network infrastructure” (I'm quoting Wim Vanderbauwhede here, from a private conversation).

For the end-users' devices, it's more complicated, but not out of reach: we want users to keep their devices as long as possible so, put differently, we must not be responsible for them to change their devices. There will always be people changing devices "for the hype" or on some scheduled basis (or just because the vendor stopped pushing security updates, some form of planned obsolescence, or can't be repaired; two things laws could alleviate), but there are also many people who keep them as long as possible (because they're eco-conscious or can't afford purchasing a new device, or simply because they don't feel the need for changing something that's still fully functioning.) For those people, don't be the one to make them change their mind and cross the line.

Don't be the one that will make your users change their device.

This is something we won't ever be able to measure, as it depends on how people perceive the overall experience on their device, but it boils down to perceived performance. So by all means, optimise your mobile apps and web frontends, test on old devices and slow networks (even if only emulated), and monitor their real-user performance (e.g. through Web Vitals). As part of performance testing, have a look at electricity use, as it will both be directly associated with emissions to produce that electricity, and be perceptible by the user (battery drain). And don't forget to account for the app downloads as part of the overall perceived performance: light mobile apps that don't need to be updated every other day, frontend JS and CSS that can be cached and won't update several times a day either (defeating the cache).

Optimise for the perceived performance and battery life.

Don't forget about the space taken by your app on the user's device too: users shouldn't have to make a choice between apps due to no space left on device, so when possible prefer a website or progressive web app (PWA) to a native application (you can still publish them to application stores if required, through tiny wrapper native apps).

When possible, prefer a website or PWA to a native application.

A note to product managers

The above advice is mostly technical, answering the question “What can I do as an architect or developer?”, but product managers have their share, and they're actually the ones in power here: they can choose which features to build or not build, they can shape the features, they can reduce software complexity by limiting the number of features and of levers and knobs. This will undoubtedly avoid bloat and help you make things leaner and faster.

Avoid feature creep and beware of Wirth's law.

Refrain from adding features, reduce software complexity.

Last, but not least, make sure you really need software! Sometimes you should embrace low-tech. For example, instead of developing a mobile app with accounts to identify the user so you can notify them, then maybe you could simply use SMS (assuming you have some out-of-band means of knowing their phone number, and the latency of distribution is acceptable). And sometimes what you're trying to address with software just isn't worth it, particularly if it involves IoT (remember that we should strive for fewer devices that we keep longer, not more).

Sometimes, ideas aren't even worth their impacts.

Conversely, as we'll need to electrify parts of our economy to reduce their carbon footprint, “software is one of the few sectors to start with a head-starts: we get greener at the same rate as the grid without other work needed” (I'm quoting Alex Russell here, from a private conversation), so please do use software to digitalise and replace more carbon-intensive activities.

Other pitfalls

Besides only evaluating electricity consumption on your servers, another pitfall is trying to attribute emissions to each user or request: when you have dozens, hundreds or even thousands of concurrent requests, how do you distribute electricity consumption among them? There's an IETF proposal for a HTTP response header exposing such information, and while it's a commendable idea I doubt it's realistic. My personal belief is that display of such information is often a sign of greenwashing. To my knowledge, data can only be accurate in aggregates.

If you really do want to show how green you are, conduct a life-cycle assessment (LCA): take all three scopes into account, all three tiers, evaluating impacts over more criteria than the global warming potential (GWP) alone.

Here are a couple resources if you want to go farther:

• Pitfalls to avoid when assessing the environmental footprint of digital technology (in French)
• Learn Green Software

Thanks to Alex Russell and Wim Vanderbauwhede for their feedback.

Links to sources of above graphics:

• The environmental footprint of the digital world, GreenIT.fr, Frédéric Bordage (PDF, 553 KB)
• Pixel 7 Product Environmental Report, Google (PDF, 224 KB)
• Dell Precision 3520 Product Carbon Footprint, Dell (PDF, 557 KB)
• Our World in Data: Carbon intensity of electricity, 2022; interactive visualisation
• Life Cycle Assessment of the Fairphone 4, Fairphone (PDF, 1.1 MB)
• Dell PowerEdge R640 Product Carbon Footprint, Dell (PDF, 514 KB)

This article was originally published over on Thomas's blog.