Developers Can Save The Planet, Part II: The Solution
In the first post in this series, I measured the daily CO2 emissions due to my digital activities. They are not negligible (at least 500g CO2 per day for a French person), and they are growing fast.
I understand that it's my responsibility as a software developer to develop better software. In this article, I'll explore the solutions to reduce and compensate these emissions, and check if they solve the problem. Are you ready to save the planet?
When I discuss climate change, 2 simple solutions keep popping out in the conversation. These are "magic wand" solutions: they solve the problem without requiring that we change our habits. Unfortunately, there is no magic wand.
"We just need to use more technology to reduce the effects of technology."
Engineers sometimes discover revolutionary technologies. For instance, LED lights allow us to reduce our energy consumption drastically without going to bed earlier. But nobody has discovered the LED light of smartphones yet. On the contrary, innovation and new technology, so far, have increased usage of digital devices and services. Our smartphones have bigger screens, more sensors, more radio emitters to transfer data over 5G networks.
Existing carbon capture and storage technologies are super innovative, but also very risky. The most benign option, Direct Air Capture (DAC), requires electricity... which currently emits CO2. Other solutions are akin to geoengineering, and in our collective imagination, it doesn't end well.
Maybe tech innovation will provide a solution for tech emissions in the future. But in the meantime, we're emitting a huge amount of greenhouse gas because of digital, and it's increasing 9% per year. This means we can't afford to wait for a mainstream innovation, we need to act now.
"Instead of reducing our emissions, we can compensate them by planting trees."
Carbon compensation may work to some extent, but it's not exempt from side effects.
Tree plantations aren't forests. They lack biodiversity, the trees are often cut at a young age to serve as wood, the net effect of which is a CO2 increase.
Also, trees emit methane, which is a powerful greenhouse gas. Could it cancel their effect on the climate? Scientists aren't sure yet.
We'd need a huge surface of forest to compensate our past CO2 emissions - about the size of the United States. Unfortunately, the land isn't cheap, and it's unlikely that all Americans will move out to let trees grow.
And how about future emissions? With a 9% increase every year, digital greenhouse gas emissions double every 7.7 years. We'd need twice the land every 7.7 years to compensate that. This sounds like the wheat and chessboard problem, which ends either with a ruined Indian ruler, or an executed chess inventor (several versions circulate). None of the endings is a good sign for us.
I made many mistakes in my carbon footprint estimate. It's partly because I'm not trained to do a life cycle assessment. But it's also because I lack the data and the models to do it properly.
It's hard to find evidence about the carbon footprint of digital. One major progress came by the publishing of the Digital Environment Repository by a French think tank called The Shift Project. I used their data in my first article. But it's still very hard to assess the footprint of digital usage, i.e. of the impact of software.
I found a few online tools assessing the carbon footprint of web apps. They produce rough, partial estimates, sometimes based on nothing scientific. Estimating only client-side or network emissions encourages optimizations that move the carbon emissions from one part of the system to another part where they are not accounted for. This does not improve the emissions of the entire system - it's called a transfer of pollution.
The most recent models from research teams are still limited in scope (e.g. PowerAPI, the most accurate power model for CPUs that I know, requires Linux, an Intel Sandy Bridge computer architecture, and does not run in VMs). Good luck using it to assess the emissions of a mobile phone.
Finally, no tool gives an overview of the total energy consumption of a software (including all its components, the client, the network, the server, the database, etc.) for a given scenario. My company is working on that question: we're currently building Argos, a service measuring the ecological footprint of web and mobile apps. But until we have something ready for prime time, we're left with partial evidence and assumptions.
"If you can't measure it, you can't improve it", yet we must improve energy efficiency in software. What can we do?
We do have a few certainties, though. The more we use digital devices and services, the more CO2 is emitted. A large share of the digital impact on climate comes from the embodied CO2 in devices. We can derive good practices from these certainties.
Some features encourage digital usage, as proved by behavioral studies. We should avoid them:
- don't design addictive experiences
- don't develop autoplay
- don't develop infinite scrolls
- don't offer unlimited offers
- don't build in social sharing
- don't build gamification
- reduce notifications
If a feature requires a recent terminal, look for an alternative solution. For instance, augmented reality, blood-oxygen levels measurement, on-device AI all require specific hardware. Building software that requires that hardware incites people to change their device.
These practices apply to the design phase before the first line of code is even written. They are, in my opinion, the most effective on CO2 emissions.
Reducing waste is always a good idea, especially network, CPU, and storage waste. The following practices help reduce that waste:
- reduce image and video size/bitrate
- avoid running programs in the background
- use video formats instead of animated GIF
- use a cache system to avoid repeated network calls
- warn users when they are wasting resources, and/or stop the waste for them
- resist the urge to add 50 tracking tags
- delete or summarize data that is more than 1 year old
Also, in client-server architectures, it's always a good idea to pre-generate data on the server-side if it doesn't change depending on the reader. So prefer a static website generator to a dynamic blog engine like WordPress, which needs at least 27 database queries per page.
If you have the choice of a programming language, prefer a compiled language over an interpreted one, try Rust, and avoid TypeScript (!). Some technologies are so wasteful they shouldn't even be considered (I'm looking at you, blockchain).
Some cloud providers allow you to calculate the CO2 emissions of your infrastructure. I have tried the Microsoft Azure Sustainability Calculator and found it... confusing. But most cloud providers don't provide any such feedback. And they never communicate the computer models their cloud runs on. Good luck figuring out the footprint of a vCPU when it can be run by 10 different CPU models...
But there is one thing that I know: the longer I run a service, the more it costs. The more servers I need, the higher the bill at the end of the month. So 2 metrics that are highly correlated to carbon emissions are also correlated to the amount at the bottom of the monthly bill. So my opinion is that the amount I pay for hosting each month is a good indicator of my carbon emissions.
But going for the cheaper host can be counter-productive. Host providers in China may be cheaper, but they're often using energy powered by coal. On the other hand, the Swiss provider Infomaniak looks expensive at first sight, until you realize that being a "Green Host" costs them money.
So to nuance what I just said earlier, look for a green host first, then start optimizing costs.
One important note about hosting: minimize log retention. It's fine to log a lot to get validated learning (and to measure energy consumption) but synthesize the learning quickly, then reduce the log levels and erase the old logs.
Finally, the least CO2 emitter software is a software that doesn't exist. You always have the choice to refuse to develop an app or a website that adds minimal value to customers, but that harms the environment big time. The current shortage in developers gives developers power, we should use it for the greater good.
Apart from that, ignore advice like "write clean code", because a) Nobody agrees on what clean code is, and b) Nobody measured the difference in energy efficiency between clean and dirty code.
I found a few guides about "good practices" for sustainable development. Most of them reuse Web Performance Optimization (WPO) techniques, which reduce client-side delays. I encourage you to check them. For instance, here is the list of 115 best practices from the French company GreenIT.
These practices aren't better or worse than the ones I listed above, because nobody is capable of proving their effects (see The Problem of Measurement above). There is no bad advice in the lists I read - just not enough prioritization, and some (in my opinion) useless practices. With every practice I read in such guides, I try to think critically, and to see the system as a whole.
For instance, one common piece of advice is to "Use a CDN". CDNs speed up the delivery of static assets by replicating them across their servers and reducing the network latency by using custom protocols. The replication and protocol translation requires more CPU. How much energy does that consume? I have no idea. Is it compensated by the CPU gains on the client-side? Maybe, maybe not. But one thing is clear: it's not a net gain without side effects, so I'd prioritize other advice first.
Another piece of advice from the GreenIT book is "Prefer single quotes to double quotes". This only makes sense in PHP, but even there, I am skeptical about this making any difference these days - and others proved there is none.
So how to find the best set of good practices? Unfortunately, there is no consensus yet, and not enough data to drive it.
Apart from building better software, I can also reduce my digital consumption. After all, we're all in this together. Here is what I can do:
- keep electronic devices for a longer time (at least 5 years)
- buy only devices than can easily be fixed
- buy second-hand / reconditioned devices
- repair what's broken, don't change it
- turn off devices when not in use
- put a timer on every plug to turn off devices at night
- watch less streaming video
- clean up old emails and files
All these require little effort and will make me richer in the long run with all the money I never spent on brand new (and useless) devices.
Reducing digital emission may make the problem worse. That's counter-intuitive, but that's what history shows us.
The Apple II Plus computer, released in 1979, consumed 200W. A modern smartphone, 40 years later, consumes less than 2 watts. A hundred times less. Problem solved?
Not so much: there are about 3.5 billion smartphones in the world, and there were only 10 Million personal computers in 1979. If I do the math:
- 1979: 200W x 10M devices = 2GW
- 2020: 2W x 3.5B devices = 7GW
By making more efficient devices and services, we make them cheaper and easier to use, and therefore more accessible. This can lead to an increase in usage.
This kind of negative feedback is common in systems theory. We should expect it: after all, the digital ecosystem is a system, too.
Some of our efforts will fail. But that's not a good reason to avoid trying.
If I reduce my digital usage, and my neighbor buys a new gaming rig every year, his actions will cancel mine.
If I develop an app that requires less screen time from its users, and another editor develops an app that takes more screen time, users won't reduce their screen time.
Although developers can have a huge impact on climate change, my conviction is that it won't be enough. I think that the real solution is to limit the harmful behaviors at the society level, to turn the good practices into laws.
Also, developers alone won't reduce the CO2 emissions of electricity, transportation, industry, residential, agriculture, and land-use change. Governments across the world have a plan to reduce CO2 emissions, but it's usually a complicated (and expensive) one. Measures such as better home insulation, taxes on car emissions, subventions to public transport may help reduce some emissions. But lobbies form a strong opposition to these measures, and the plan isn't yet fully translated into actions.
In addition to my actions as a developer, I know I must also act as a citizen, and support the global fight against climate change.
As much as I'd love to have a working solution to solve the digital emissions problem, I don't. In the absence of a reliable CO2 emissions measurement, all sets of good practices are questionable - including mine. But I'll follow them myself because we just can't do nothing about global warming.
In my opinion, the absence of a consensus is actually good news. We have the liberty to be creative, instead of following a set of rules. We can use our collective intelligence to solve the problem. We can exercise our engineering skills for a good purpose.
Developers alone won't be enough to save the planet. But the planet rescue team won't make it unless they embark a lot of developers.