Measuring the effects of going green in software development

The imperative for companies to adopt environmentally conscious practices in software development is gaining traction, driven by a range of motivations—be it idealistic aspirations (helping to save the environment), pragmatic considerations (green software development has proven to be cost-effective), compliance to (almost certainly soon to be introduced) regulations and laws, or even a more cynical pursuit of improved public image.

In this era of heightened awareness, businesses increasingly view the shift towards greener software development as an intriguing investment. Besides the obvious benefits, this ‘green shift’ can serve to streamline – directly and indirectly - the entire software development cycle. How, you ask? By forcing a more professional and holistic approach to building and maintaining software. A green shift requires thorough analysis, which may serve as documentation and can uncover all kinds of inefficiencies. Solving these inefficiencies can decrease development and maintenance costs, heighten developer velocity, or increase performance and code clarity.

But the question arises: what does a company need to do to start this green shift, and more critically, how can they measure success?

The goal of green software development is carbon efficiency: emitting the least amount of carbon possible per unit of work. Though there are various considerations in green software beyond carbon emissions. The intended use of the software, for example: does it assist in fragging, or is it meant to help preserve the rainforest? Software development also indirectly influences hardware production and disposal, and this hardware may in turn contain hazardous or even toxic materials. However, reducing carbon emissions remains paramount.

The goal of minimizing carbon emissions naturally extends to energy efficiency, with the understanding that electricity serves as a proxy for carbon. Designing an energy-efficient application equates to one that is carbon-efficient, taking responsibility for minimizing electricity consumption.

Next, quantifying the energy consumption of an application is a vital step, but it is not the sole consideration. Power usage efficiency (PUE) and the concept of energy proportionality add layers of complexity, shedding light on the efficiency of hardware utilization. This insight helps make transparent how applications behave in real-world scenarios concerning energy consumption.

Embodied carbon – the carbon emission during the creation and disposal of a device – underscores the importance of extending the lifetime of a device to amortize its carbon emissions. Hardware will always eventually break down, but applications that run on older hardware and extend their lifespan indirectly decrease carbon pollution.

Due to embodied carbon, cloud computing emerges as a more energy-efficient alternative to on-premises software. It’s better to use one server at 100% utilization than 5 servers at 20% utilization because of the cost of embodied carbon. Cloud computing offers the flexibility to apply demand shifting and shaping.

Measuring carbon emissions serves as insight into the current status, but also as the starting point for a strategy, serving as a baseline and comparison point for the future. The goal is a series of measurements over time.

Measurement is usually done using the GHG protocol, classifying emissions into three scopes:

1. Direct emissions;
2. Indirect emissions, related to purchased energy;
3. Other indirect emissions from the entire supply chain, business travel, and product usage.

However, calculating software-driven emissions like these is very complex and tends to be extremely challenging. Most companies require help from a consultancy company to even approach a useful measurement this way.

Alternatively, the Software Carbon Intensity (SCI) metric, developed by the Green Software Foundation, quantifies software emissions based on energy consumption, location-based marginal carbon emissions, and embodied emissions, with a functional unit.

To calculate the SCI score, companies:

1. Decide what to include, ensuring all significant components contributing to software operation are accounted for.
2. Choose a functional unit that best reflects how their application scales.
3. Decide what to use for quantification; either measurement via real-world data or calculation via models, with resources like the Software Carbon Intensity Guide providing guidance.
4. Quantify the SCI score for each software component within their boundary, considering multiple scenarios to understand their application's behavior in diverse contexts.

A problem for both GHG and SCI is that companies can pick and choose what to include. This decreases the objectivity of the measurements. Another problem is that it is a lot of manual work. But software development means automation, and luckily, automation is possible even in this regard.

There are multiple examples of adding automation and objectivity to your green measurements.

Take, for example, the CAST Highlight tooling. It will combine a survey with a technical analysis of your application(s), and output a Green Impact Score, estimated CO2 emissions, and possible remediations and recommendations. The survey, of course, introduces some subjectivity and manual work, but the scan is fully automated and cannot be configured.

Using CAST Highlight and the SCI Specification, CAST demonstrates that decarbonizing a single software application can potentially reduce annual CO2 emissions by an estimated 400 kg—a testament to the tangible impact of green software practices.

Alternative tools are available, as well, and more alternatives will show up in the future when the business model of automating green shifts takes off.

Another, even less involved way to measure the environmental impact of software is available to companies hosting software in the Azure cloud. The Emissions Impact Dashboard automates the calculations of the emissions of a company’s cloud resources and visualizes them using Power BI. This has the additional benefits of standardization, easy intercompany comparison, and the possibility to calculate how to further reduce emissions based on live data.

Measuring the carbon emissions of software applications and their development cycle is becoming increasingly mainstream. Standardization makes these measurements easier to perform, and more useful, and they can increasingly serve to make attainable green alternatives transparent. Investing in green software analysis and/or a green shift strategy now can potentially be a profitable investment in more ways than one.