Apply the conclusions of the ADEME studies on the digital impact to software development.

This article was updated on April 28 2023. Please find the comment about this update after the article .

When I started posting again, my plan was to do it every week or 2 weeks. Considering that the last one was published on February 16th, you could say I've failed. Indeed, but there's a reason: I fell into a rabbit hole, the study of the sustainability of AI.

Along the way, I'm still learning many facts and studies on the sustainability of digital that I'd like to share without writing a whole book. I think a good recipe would be to focus on one small lesson or discovery and share my thoughts about it. That's what I'm going to do today in this blog post.

The ADEME (the French Agency for Ecological Transition) and the ARCEP (the French Regulatory Authority for Electronic Communications, Postal and Print Media Distribution) have published a study in 2 parts about the impact of digital in France a year ago (recently they published a third part focusing on the evolution of the impact for 4 different scenarios). To analyze the impact of the French digital as a whole, they have decomposed the digital in 3 parts (terminals, networks and data centers) and [assessed their life cycle] (https://en.wikipedia.org/wiki/Life-cycle_assessment).

If there are known limitations (e.g. some excluded network hardware, non-French services), the conclusions are quite significant and in line with other studies (more about this in a next blog post):

  • The main environmental impacts are depletion of fossil resources, carbon footprint, ionizing radiation, and depletion of abiotic resources (minerals and metals),
  • Terminals account for most of the impacts, from 65 to 90%,
  • Considering every life stage, terminals are responsible for more than 80% of the depletion of abiotic resources, and about 80% of the carbon footprint,
  • Considering each device, use is responsible for about 80% of fossil resource depletion and ionizing radiation, and
  • Data centers are second only to the terminals, and the manufacture and use of servers account for about 50% of their impact.

For consumers, one of the most obvious takeaways from these conclusions is to extend the life of their devices as much as possible. As software developers, we have a role to play in helping them do that: to create software that doesn't make old devices obsolete.

The power consumption of software depends on the way it is built: the stack used (programming languages, libraries, and third-party services), the number and type of features, and how they are implemented. We can then act on their implementation efficiency, but also on their feature relevance: a feature can be implemented efficiently, but still be a waste because it's not really useful to the user. For example, many mobile app trackers aggressively monitor the user beyond reason: they are a waste of energy.

When it comes to the stack, this is a trickier question because it also depends on what you know. Over the past decades, we have favored stacks that allow us to build software quickly, rather than reducing its power consumption. This is not something we can change in a day. That said, it can guide us in a given ecosystem (e.g. web client) to choose one framework over another: you may not need a javascript framework like Vue.js or React when modern CSS can do the job.

These principles are a bit too vague because they don't give us goals to achieve. When do we stop? When is enough? If we are serious about delivering our software on some old hardware, this should be part of the requirements. That's why I would pick some client hardware that I want to support from the start. We can then check along the development that it works on those targets.

When it comes to the server, we can follow the same principles and approach. I would add that we have a word in their choice. Whether it's bare metal or cloud, I would go with the most common hardware and avoid any exotic hardware. There are other considerations to take into account, such as the vendor and its repairability. But that is beyond the scope of this topic, perhaps for a future time.

There are also things you can't change except not to use them, such as third-party services or libraries. The rest is about decreasing computing as a whole.

I'm aware that there are tools, guidelines, and frameworks for improving the sustainability of IT. They probably start from the same observations. I still think it's interesting to go down the path myself to develop a deep understanding of the topic.

What about you? How do you approach this question when you do?

Update 28 Apr 2023:

A reader reported to me 2 unclear or wrong sentences:

  • The production of terminals is responsible for more than 80% of the carbon footprint and the depletion of abiotic resources,
  • terminal use is responsible for about 80% of fossil resource depletion and ionizing radiation, and

This was confusing and misrepresented. Here's what I wanted to say originally:

  • Considering every life stage, terminals are responsible for more than 80% of the depletion of abiotic resources, and about 80% of the carbon footprint,
  • Considering each device, use is responsible for about 80% of fossil resource depletion and ionizing radiation, and

Also, thanks to the discussion I had with him, I realized that I hadn't clearly stated that the study focused on France. This means that you can't apply the ratio to other countries, especially regarding the carbon footprint of use. For example, Belgian electricity production has a carbon footprint 3 to 4 times greater than that of France.

The method remains valid and some conclusions can be applied to other countries. Also, the ratio is not a good way to report these amounts: even if the carbon footprint of use is larger, the carbon footprint of production is about the same. We are still starting with a significant "debt", which is increased by use.

If you have any comment, question, or feedback, please share them with me.

Atom feed icon Subscribe to the blog!