The Top 10 myths of frugal ICT

Posted on by Olivier PHILIPPOT
Reading Time: 5 minutes

I have been working for more than 8 years in GreenIT and I have seen lately that several studies and initiatives have started. This is a very positive sign and shows that there is a real dynamic to change the impact of ICT. All actions, whether small scale, as a simple awareness, or on a larger scale such as the optimization of a website with millions of visitors, is good to take into account the climate emergency.

However it’s important to avoid any greenwashing phenomenon and to understand the impact of the good practices mentioned (are they really all green?)

Myth 1 – A powerful software is a simple software.

False

A powerful software is a software that will be displayed quickly. This gives no information on its sobriety. On the contrary, it’s possible that practices are put in place for a quick display and that they go against the sobriety. As for example put the loading of the scripts after the display of the page. The page will be displayed quickly but many processes will run in the background and will have an impact on resource consumption.

Myth 2 – Optimize the size of queries and the weight of the page, this makes the software more frugal.

True and false

True because actually fewer resources will be used on the network and servers. Which means less environmental impact. It goes in the right direction.

False because the evaluation of a simple software will not only be based on this type of technical metrics. Indeed, it is possible that certain elements have an equally important impact. A carousel on a home page could for example be quite light in terms of weight and requests (for an optimized carousel) but in any case will have a strong impact in user-side resource consumption (CPU consumption, graphics … ).

Myth 3 – Automatic control via tools allows me to be green

True and false

True because it is important to measure the elements. This will allow to know objectively where we are, and to improve.

False because the evaluation will be done on technical elements. There is a bias: we only measure what we can automate. This is the criticism that can be made for example on Lighthouse (accessible tool in Chrome) on the accessibility. We can make a totally inaccessible site by having a score of 100. This is the same criticism that we can have about the tools that are used in ecodesign. For example the website http://www.ecoindex.fr/ is an interesting tool to initiate the process, however the calculation of this tool is based on 3 technical elements: the size of the page, the number of request and the size DOM. These are important elements in the impact of the page, however several other elements can be impacting: CPU processing from script, graphic processing, more or less good solicitation of the radio cell … All elements that can create false positives.

A measurement software will be complementary 😉

Myth 4 – My software uses open-source and free code, so I’m green

False

Free software is a software in its own right. He suffers the same obesity as other software. He will therefore potentially be a consumer. On the other hand, free software has a stronger capacity to integrate good efficiency practices. Still need to implement or at least begin to evaluate the impact of its solution …

Myth 5 – The impact is more on the datacenter, on the features, on that …

True and false

Any software is different, by its architecture, its use, its implementation, its functions … no serious study can certify a generality on a domain that would have more impact than another. In some cases, the impact will be more on the datacenter (for example on calculation software) but in other cases it will be on the user side (for example mobile applications). In the same way, some software will be obese because of their multiple functionalities whereas others will be because of a bad coding or an external library too heavy.

Myth 6 – Ecodesign requires a structured and holistic approach

True and false

True because indeed it’s necessary to involve all the actors of the companies (developer but also Product Owner, Business Department) and to have a coherent strategy.

However, starting process and product improvement through unit and isolated actions is very positive. The heaviness of the software is indeed in a state where any isolated positive action is good to take.

Both approaches are complementary. Avoiding the application of certain practices while waiting for a structured approach (which can be cumbersome) would be dangerous for the optimization and competitiveness of your software.

Myth 7 – The green coding does not exist, the optimization is premature …

False

This is an argument that has existed since the dawn of time (software). Code implemented, legacy code, libraries … optimization tracks are numerous. My various audits and team accompaniments showed me that optimization is possible and the gains are significant. To believe otherwise would be a mistake. And beyond optimization, learning to code more green is a learning approach that is useful to all developers.

Myth 8 – My organization is certified green (ISO, ICT responsible, Lucie …), so my product is green.

False

All its certifications will effectively ensure that you are on the right track to produce more respectful software. Far be it from me to say that they aren’t useful. However, it must not be forgotten that these are organization-oriented certifications. In a structured industry (like agriculture, a factory …) the company’s deliverables are very aligned to the process. Certifying an AB farm will ensure that the product is AB good.

However in the mode of the software it is not so simple, the quality of the deliverables is indeed very fluctuating, even if one sets up a process of control. In addition, an organization potentially consists of a multitude of teams that are not going to have the same practices.

It’s therefore necessary to control the qualities of software products and this continuously. This is an approach that will be complementary to the certification but mandatory. Otherwise we risk discrediting the label (see going to greenwashing).

Myth 9 – Optimizing energy is useless, it’s the equivalent CO2 that is important to treat

False

The ecodesign work is mainly based on the reduction of equivalent CO2 (as well as other indicators such as eutrophication …) over the entire life cycle of the ICT service. It’s therefore important to take into account this metric. Without this, we risk missing the impacts of IT. However, on the same idea as points 5 to 7, no optimization is to be discarded. Indeed, it is necessary to understand where the impacts of the software are located. However, the integration of the energy problem in teams is urgent. Indeed, in some cases the consumption of energy in the use phase is only part of the impact (compared to gray energy for example). However in many cases, high energy consumption is a symptom of obesity. In addition, in the case of software running in mobility (mobile application, IoT) energy consumption will have a direct impact on the renewal of the devices (via the wear of the battery).

Myth 10 – I compensate so I’m green

False

It’s possible to offset its impact through different programs (financing of an alternative energy source, reforestation …). It’s a very good action. However, it is a complementary action to an ecodesign process. It is indeed important to sequence the actions: I optimize what I can and I compensate what remains.

Conclusion

The frugal ICT is simple because it’s common sense. However, given the diversity of the software world, the findings and good practices aren’t so simple. However, the good news is that, given the general cumbersome software and the delay in optimization, any action that will be taken will be positive. So don’t worry, start the process, it’s just necessary to be aware of some pitfalls. Be critical, evaluate yourself, measure your software!