GreenCoding: The keys to lower emissions

Published in

gft-engineering

11 min readMar 22, 2021

How we can make software part of the climate solution.

GreenCoding: The keys to lower emissions

Reducing greenhouse gas (GHG) emissions is an urgent global priority. It has recently been underlined by commitments from both the political and business spheres. By 2050, the Biden administration has pledged a trillion-dollars of clean-energy investments and the EU has committed to becoming carbon-neutral by 2050. And Blackrock, the world’s largest money manager, which in 2020 pledged to put sustainability at the heart of its investment strategy, is just the most prominent of many investors and corporates now pivoting to climate-friendly business models.

Yet while emissions need to fall fast to meet global commitments, the power demands of information and communications technology (ICT) are moving in the opposite direction. Although it only accounts for 5–9% of electricity consumption today, it’s estimated that by 2030, ICT could account for as much as 21% of global electricity demand. If all the energy it needed came from zero-carbon sources, this might not be a problem. But in 2019, only 11% of the world’s primary power came from renewable generation and this will not change dramatically overnight. There is therefore a pressing need for technology to take an approach that reduces its demands for energy and resources, all the way from production to end use.

When assessing their GHG emissions, most companies focus on Scope 1 and 2, which cover direct emissions, for example from burning fuel, and indirect emissions from purchasing electricity. However, technology companies mostly have low GHG emissions in these categories. It’s in Scope 3, value chain emissions, where the bulk of their environmental impact happens. This covers indirect emissions that arise, for example, from the use of their products. Of Microsoft’s expected 16 million metric tons of carbon emissions in 2020, around 75% were in Scope 3.

Coding is typically about efficiency of effort. What if it could also extend to energy efficiency — and so become part of the climate change solution?

There is immense potential. Software with open-source code is likely to contain redundant sections that could waste network and CPU parsing time. The choice of image format and visual design has an impact on loading times and user journeys: scaled up to thousands of users, poor choices can translate into days of extra operating time. Even decisions about how long information should be retained can impact on caching and efficiency.

Time for a change of mindset

At the moment, there’s little awareness of the potential for sustainable software development. This is driven, at least in part, by a conflict of interest between development and operating budgets. Making software more efficient costs time and money but efficiency is essential to keep operating costs low. Managers want the efficiency: but to deliver it, developers need more time and resources.

What’s needed is a change of mindset. If sustainability and efficiency are the goals instead of initial cost, managers can focus instead on optimising software end-to-end, which will ultimately drive operating cost, energy efficiency and performance. Software analysts, architects and engineers all need to engage with this new mindset because ultimately, the efficiency of computers depends on the software they run. All code has a footprint and it should be a small as possible. The energy-saving potential is huge: scaled up to servers worldwide, and beyond them to consumer devices, every line of code has the potential to reduce energy consumption and emissions.

The scope and potential of GreenCoding

GreenCoding, as we call it, is based on architectural principles and supported by three pillars: the logic, methodology and platforms used to write, develop and run the code.

*The three pillars of GreenCoding at GFT*

Greener architecture

Sustainable software development starts with three overarching principles that should form the basis of all subsequent decisions.

1. Shut down when idle

Just as you would switch off the lights when there’s no-one in a room, software should be shut down when no-one is using it. This means designing applications according to modular principles so they can be shut down separately. Central to microservices and serverless architecture, this approach covers scalability and stopping/starting replica modules due to demand fluctuations, as well as total shutdowns. Make sure code is always in a position to separate individual sections and transform them into new and autonomous modules.

2. Avoid impulsive consumption

Is real-time processing necessary? If software includes asynchrony, jobs can be collated for clustering and processing together in sequence. If they are not checked to see whether they need processing in real time, all processing could be carried out in real time by default, increasing energy consumption. Analysis could reveal that hourly or even end-of-day processing may be appropriate. You can apply the same approach to the landing page of a web application that has inner sections based on dynamic content but initial landing content that changes only daily. Here, you could use static site generation techniques to rebuild the page per release, per week, day or even hour, transforming dynamic content into static content that is much easier to optimise in terms of energy consumption.

3. Focus your time and energy investment

This third principle of greener architecture looks at the overall lifecycle of software: its creation, use, maintenance and disposal. Seeing the big picture means starting with the software’s target audience. What is it? Humans or other machines? How many users will there be — dozens or thousands? Drilling into the detail here will help you understand usage frequencies and the duration of average interactions. Use this analysis to identify which architectural elements will need most energy, and therefore where you need to invest time and effort. For example, in an application that generates thousands of images every hour, saving even 0.1 of a second to load an image could save significant energy over time.

When a millisecond is worth two days
Reducing the resolution of screen images on a mobile app with 500,000 users could save over 2 days of operating time a year, assuming the average user opens the app once daily.

In GreenCoding, assigning relative energy footprints to different elements of the software lifecycle — for example, development, testing, servers or mobile device users — will also help to prioritise time and investment.

Greener logic

Once the architectural foundations are set, every decision matters. Even though a single optimisation may have a negligible impact on its own, it could make a noticeable impact when combined with many others. We have identified four areas that could deliver potential GreenCoding performance enhancements:

1. Benefit-driven visual content

With a large user base, every millisecond of system usage counts, as does every piece of content that users ignore. But providing the optimal experience for every user is notoriously difficult. With an economical approach to visual content that’s focused on user benefits, different use cases can provide different levels of information for each user path. Preventive techniques develop smart visual design during concept development, while corrective approaches use behaviour tracking to pinpoint typical user journeys. And as well as saving energy, giving users what they want, faster, also improves customer satisfaction.

2. Zero-waste code

Free, open-source software has had a huge positive impact on delivery times and resource investments. Today, 90% of software contains open-source code developed by third parties. And while it’s sometimes a perfect fit for the problem to be solved, it’s also likely that it will introduce redundant sections of code. This can mean wasted network time and CPU parsing time and can also increase initialisation time for mobile or desktop applications.

You can prevent bundle size issues by allocating a size or performance budget that alerts developers when the budget is depleted. The first step is to focus on code that will never be executed. Because doing this manually can be time-consuming and risky, “tree-shaking” engines offer a good alternative for removing “dead” code — as long as developers pay attention to their sensitivity. Open-source providers are already paying attention to software footprints. Growing awareness of GreenCoding could accelerate this trend.

3. Low-footprint resources

Although code is the foundation for saving on processing resources, software is also impacted by how information is organised. For example, if an inefficiently structured file has to be parsed and transmitted hundreds of times every hour, it could have an impact on energy use. Using simpler file formats for storage — CSV instead of Excel, or YAML instead of XML — can help.

GFT research shows that even API choice can have a direct impact on GHG emissions. GraphQL APIs are much more efficient at fetching data than REST APIs, as they make it possible to efficiently retrieve defined elements of a post. Amending REST APIs to be more precise simply makes the API more complex and still retrieves too much data. For example, replacing a REST API that fetches 100MB per session with a GraphQL API reduces the amount of data by 5MB. Based on the energy mix in Germany and assuming that one GB takes 0.06kWh to download, the table illustrates how this could translate into emissions savings.

GraphQL API emissions savings vs. REST

But it’s with images and visual content where the most impact can be made. Image packaging is important and often overlooked: a good rule of thumb is to use raster images for photographs or detail drawings and vector images for logos, symbols and charts. The emerging concept of “dark design” saves on energy used by displays, when coupled with OLED or MicroLED display technology, where dark mode on mobile devices can reduce battery use by more than 20%.

4. Proximity feeds

If information is classified in terms of how long it is needed for, this can be combined with intelligence about how frequently it is requested, to optimise caching and efficiency. The closer the cache is to the user, the better. Social media and distributed storage have raised users’ expectations of how up-to-date information should be, so it’s important to ensure efficiency gains don’t damage the user experience. That said, as long as careful analysis is carried out during the design phase, simple compromises can have a surprising impact on efficiency, while being entirely acceptable to users. As well as HTTP caching, you can also use progressive web applications (PWAs) and content delivery networks (CDNs) to tackle the proximity problem by handling content expiration and reducing the physical distance between server and user.

Greener methodology

Rapid feedback, better decisions

Once teams become aware of the energy impact of their coding decisions, change happens most efficiently if feedback can be organised into rapid cycles. Agile and Lean methods can make it easier to adapt software for efficiency, while continuous integration and continuous delivery make it possible to visualise each development decision’s impact. The feedback metric that gives the best ROI is loading time: it’s easy to measure and correlates directly with energy consumption. Developers should start by measuring “hello world” loading times and then tag each new feature and its impact. It is essential to record the before-and-after situation to get a clear picture of the ultimate benefit. Additionally, incremental building can save both direct energy consumption (CPU time) and reduce feedback loops. With this technique, developers recompile modified sections of code instead of entire deliverables, or only test rewritten code and systems affected by recompiled code.

Reusable output

No two projects, teams or business units are the same, so they will naturally take different approaches to GreenCoding. However, at the heart of sustainable software development is ensuring that the results of GreenCoding projects are widely available, within and even beyond organisations. This may mean, for example, establishing efficiency metrics so they can be extrapolated to other projects, saving teams the effort of further benchmarking. Ultimately, the success of GreenCoding depends on capturing sets of preventive measures that will be relevant to other development projects.

Greener platform

For optimum energy efficiency, the infrastructure that code runs on is as important as the code itself, with utilisation levels having a particularly strong impact.

Optimal utilisation

Why does utilisation matter? If you’re one of just a handful of travellers on a 300-seat airliner, you’ll be responsible for significantly more GHG emissions per passenger kilometre than if the plane was fully loaded. Similarly, if servers are underutilised, they will consume more energy per percentage point of computing power than if they are at full utilisation. Low utilisation is typically the result of overestimation during the planning stage and can result in systems that are much larger than they need to be. Cloud computing can offer large energy savings, as public cloud systems are highly modular and make precise control of utilisation possible. For example, AWS, Google Cloud and Microsoft Azure data centres run at approximately 65% utilisation, while on-premise data centres reach only 12–18%.

*Underutilized computing capacities waste a lot of energy*

Physical infrastructure improvements can save energy, too, reducing power demands by up to 29%: Google Cloud has taken this further, using machine learning to reduce the energy needed for cooling by 40%. Finally, ensuring a clean power mix in the energy source — which is the goal of all public cloud providers — is the final part of the equation for reducing emissions.

Precise configuration

Running software on a platform with default configuration settings is like wearing shoes without tying the laces: it works, but not as well as it could. Looking into configuration options may reveal inefficiencies, for example HTTP2 or gzip compression settings that were never enabled. Sustainable software development looks at platform capabilities during the entire lifetime of an application, not just on release.

Holistic metrics

In the longer term, you will need better metrics to refine GreenCoding strategies. As well as the energy demands of servers, this should also extend to include “hidden” infrastructure such as personal devices. These are, of course, very diverse: however, it is possible to explore energy costs in different countries to analyse the impact of wasted energy vs. GDP, income or other metrics.

Conclusion

GreenCoding is in its infancy. Yet we have seen that it aligns well with the iterative cycles and data-driven methodology of Agile development. And it can be integrated into every part of the Continuous Integration/Continuous Delivery process, transforming how software is delivered. It can be time intensive. However, this should be balanced against its benefits, which go beyond energy efficiency to include better usability and user experience and reduced operating costs.

We believe GreenCoding is a new frontier for software development and will ultimately shape how all software will be made — for the greater good. The keys to sustainable software are at our fingertips.

Find more information about GreenCoding here: https://www.gft.com/GreenCoding

Get the GreenCoding whitepaper

Gonzalo Ruiz de Villa Suárez, GFT CTO
Benedict Bax, Executive Assistant to the CEO, GFT