Ladies and Gentlemen — I present to you the calculated amount of time we have until the world’s average temperature goes over 1.5 Celsius (or 2.7° Fahrenheit).

While a 1.5 difference doesn’t *sound *like much…

These small numbers actually mean **huge **changes globally.

(That’s why the word average is so important).

Basically it gives us a few things to worry about.

Things like higher sea levels.

More frequent natural disasters.

Floods, hurricanes **and **wildfires.

And of course, we can’t forget those pesky **extreme heat waves **that would happen world-wide.

Basically this:

Oh but that wouldn’t be the end. Because there are also side effects we’d have to consider.

Economies and industries would change.

Agriculture will be impossible in certain areas.

Different kinds of plant and wildlife would disappear **(coral reefs especially).**

A lot of things will change sooner rather than later.

That’s why environmental sustainability has become such an important topic in the last decade and why projects like the climate clock have become key in raising awareness and incentivizing action to go green.

Awareness can help create small actions. Small actions can snowball into big changes.

But what does that mean for us in the software development field?

A lot actually.

We’re sitting in an era of exponential technological advancement the likes of which **nobody **has ever seen.

Let’s take the prosthetic arms industry as a benchmark, where one company has successfully made 90% cost-effective superior alternatives.

With that level of progress in just a few years, could you even begin to imagine what things will look like in the next 10?

Well guess what?

We’re at the FOREFRONT of these changes.

**We’re **the ones who can decide and create a healthier, better status quo.

But that’s why it’s important for everybody, from devs to designers to managers, to first understand the exact trajectory we’re going and what our current tech is causing globally.

Cause if we don’t…

Pfff, who will right?

So let’s start with the obviously-not-so-obvious.

How software affects the planet

By itself, software doesn’t do anything. It doesn’t “exist”.

It’s just a collection of symbols and characters that somebody somewhere once put together to represent logic and design.

If you never run it, nothing happens. It doesn’t emit anything.

It’s “green”.

Yet, we know better.

It doesn’t exist in a vacuum. It lives alongside the hardware that runs it.

Software is what gives hardware the instructions of what to do, what resources to use and for how long to use them. Circuitry and really small components heat up to do this, letting us process, download and upload the data we need.

Unfortunately, running this hardware isn’t free. These actions use up energy and electricity to source their execution.

Software makes hardware run → Hardware uses electricity -> Electricity production emits greenhouse gasses.

Wait, producing electricity emits greenhouse gasses?

How electricity production emits greenhouse gasses

Every country’s electrical sector, to some degree, needs to burn fossil fuels for production to meet demand.

Even with the incredible advancements we’ve made with greener methods like harnessing solar or wind, we still haven’t reached a level where zero emissions in production are possible.

And to give you an idea of how bad this can be…

In 2019, electricity production accounted for 25% of total emissions in the US alone, becoming the second largest source right behind the transportation sector. And we’re expecting these numbers to grow in the coming years.

With this, we’re starting to see how software plays its part in all of this.

What we haven’t talked about is when and how exactly software forces hardware to use up more or less energy in any given time.

How software causes us to use electricity

In the context of the software production sector, there’s 2 main areas where we can say electricity is needed:

During the production of the software
During the use of the software by the users themselves

You can think of production as everything involved in a project cycle. The hardware that is run to power online meetings, design programs, development, planning, testing, internet connections, fixing errors, monitors, battery charges, office lights, Spotify, everybody’s air conditioning, cell phone use — everything you would associate with an electronic resource being used during a project.

For the second case I mentioned, we’re talking about how much electricity is needed to run the software for the users. (Everything related to what happens after development is done and is being maintained)

Using a simple example, you are on a website right now. When you decided to click on the link that led you here, your browser connected you with the web server that holds the code and information of this website.

In (hopefully) just a few seconds, your browser downloaded a few files from that webserver.

All of this so that your browser can then run the code (what we usually know as HTML, CSS and JavaScript) to reproduce the structure, design and logic that a team of developers wanted you to see to read this article.

All of that consumes energy along the way.

There’s actually more to this other than these two scenarios.

In both cases, we’d still need to consider the infrastructures, servers and services that need to be run alongside the software. The hardware that is run that we DON’T see.

Think datacenters, databases, cloud computing, CRMs… all the technology needed just to run and maintain the handling of data during both the production and use for the user.

With data centers for example, they use electricity for the running and cooling of their hardware. No matter how indirect, we still have to take this into account if we want to know all the variables.

This puts software into a strange place, doesn’t it?

It’s as if software is an invisible waste product.

It’s not always obvious what happens every time we turn our computers on for the day. Or every time we need to build and deploy code.

A lot of things happen in the background that we directly don’t see.

So is there a way to reduce some of this waste, however small? And do so systematically so that we can set it and forget it?

Can we make small changes that can be the catalyst to bigger change?

Let’s find out.

How can you measure the sustainability of software?

Measuring how “green” a given piece of software is has always been pretty tricky. Some of the reasons are:

Software rarely runs by itself. On a computer, there are usually hundreds of other small programs, processes and services running on your device at the same time. Unless tested under very specific conditions, knowing the energy consumed from one or a collection of processes is rarely straight forward.
We mentioned before that sometimes software uses other services outside itself. Going back to the data centers example — your project’s choice between a data center that chooses to burn fossil fuels vs one that opts to use greener energy changes the total number. Even then, you usually don’t know how much energy used by that data center was dedicated to your software. Not to mention a lot of times, data centers don’t report on electricity used! So finding and choosing these numbers isn’t easy.
Depending on things like what hardware and OS you’re running on, the same program run on different machines can use up different amounts of resources than the other. Heck, even the same kind of machine in some cases can have different electrical use.

Take modern operating systems for example: After just a few weeks of being installed, the machine’s OS learns to optimize its resource allocation better. For this reason, a new machine that’s been running for a few weeks ends up consuming **less **energy than one that’s been installed yesterday.

OH! We also can’t forget that virtual machines are also a thing — pieces of software that simulate other pieces of software. Would the energy used on a simulated machine be the same as one run on a non-simulated machine? Would resource allocation and usage the same? Probably not!

So no, while it would be almost impossible for us to get practical measurements of sustainability in our software, the best we can do is estimate.

But even that isn’t always easy.

The best attempt I’ve found of trying to create estimations has been this study which I think is worth a read.

In the case of websites, there are tools like Website Carbon which do give us a good number, down to how much CO2 is used for every page open.

In most other cases…

Outside of measuring a device’s general electricity use and estimating any external services your software uses, we’ll never have one magic number.

Although… There are other indirect numbers we can measure instead.

How to improve the sustainability of code and projects

In the world of sustainability, there is something called “the 7 Rs”.

These are:

Refuse
Reduce
Reuse
Re-purpose
Repair
Rot
Recycle

The idea behind these is if we try and follow these 7 principles, we’ll be on a road to a more sustainable future.

So maybe, instead of measuring things like the amount of waste or electricity used in our work and reducing that…

An alternative could be to measure our progress in implementing these principles in our work, measuring that progress and improving upon it that way.

It’s not perfect, since these 7 Rs are associated with physical products and their life cycle. Not all of them might not be applicable in our work.

But hey, let’s see which ones do. Starting with:

1) Refuse — Say no to decisions that could create waste.

Originally this principle is related to reducing buying decisions or actions that could create extra waste. Things like buying too much food and risking it going bad, avoiding products that aren’t sustainable or ones that create a lot of waste.

For software projects, refusing could mean:

Saying no (or negotiating) client requests or projects that go against our sustainability values.
Refusing or negotiating a client’s new software requirement with a more sustainable alternative.
Refuse going with non-green data centers or services in your software and opt into using more sustainable ones.
Refuse integrating full libraries or packages in your solution when you know you’ll only use a small portion of its code. Prefer using custom code or smaller and lighter libraries.

The only drawbacks to this is it might lead to projects that might end up being more expensive or time consuming for the client and development.

Who knows though. Maybe being able to position your proposals as a “sustainability focused project that follows our strict green values” could make the extra expense and time worth it for certain companies. And that market will be growing in the future.

As a side note, this principle seems to land more as a high level issue. One that will depend on a company’s policies and a sustainability approach to selling.

It will probably take a little creativity to execute effectively.

Onwards!

2) Reduce — Minimize waste

A lot of what we do creates waste. The original principle relates to actions we can do to reduce the waste we might produce. (Instead of out right reducing, we’re looking for ways to minimize damage)

Examples include utilizing reusable bags for groceries or choosing products that create less waste would go in this category.

For software projects, reducing could mean:

Opting to go with (or upsell) more sustainable or greener projects than wasteful ones.
Implementing systems or guidelines for those involved in a project to reduce their own electricity use. Something as simple as lowering your screen brightness from 100% to 90% can be big in the long run.
Use good design principles to minimize a user’s time spent on your software trying to find something. An x amount of CO2 is produced for every page click. What would happen if on average users clicked on one less page per session?
Create solutions that reduce the use of resources on developers and user devices. This includes things like optimizing, reducing file sizes, compressing, minifying and refactoring code.

One tool that could be incredibly helpful for estimating resource use is Big O Notation.

It’s a concept used in computer science that estimates how fast an algorithm grows over time. The idea is the more “complicated” it is, the more memory and CPU resources it will consume. So if let’s say you manage to lower the O(n) number down, then:

Less resources used over time -> less electricity used per execution -> more sustainable.

3 & 4) Reuse and Repurposing — Extend the life of products.

Products don’t always have to be “single use”. Most of the time they can be reutilized more than once or in new ways. Even if not by you, you can give it to somebody to use them themselves.

Or even better, with a little creativity they can be used in ways they weren’t intended for. Old clothes can be cut up to be used as rags. Paint buckets can be turned into pots for plants.

For software projects, reusing and repurposing could mean:

Reutilizing already optimized code, templates, emails, proposals and designs from other projects to reduce development time in newer, similar projects. Maybe even share that with other co-workers.
Contributing to open source projects and libraries (or you know, stack overflow). This will not only help you but also other developers with their own projects or with their own problems.
Repurposing existing designs for new projects. Having a swipe file of designs from past projects can be a huge time saver for designers.

The idea behind it is: If I created something, is there a chance I can “extend” its life by saving it and helping my future self, a future team or somebody else in the process?

As an extra and important side note, here’s an article by Erik Dietrich on the code reuse philosophy. When it comes to code, it’s a good perspective to put effort into avoiding duplication. Not necessarily focusing on reusing code. Quite a distinction.

As for the last three Rs…

it seems like they don’t apply, since software doesn’t cause physical waste (unless we’re talking about hardware, but that’s a talk for another day). There’s no need to repair, rot or recycle the software itself.

Hopefully this article helped clear the air around the invisible impact software has on our lives and what actions, no matter how little, we can start to do towards a greener future.

This is only the tip of the iceberg I’m afraid.

There’s still a lot to talk about this topic and how this could be implemented professionally in our day to day. Unfortunately, these are the kind of changes that will only happen with purposeful action.

It would involve being systematic in its implementation and as part of a company’s culture.

The hardest part would probably come from choosing what **to measure, the **action **of measuring itself and the **behavior change needed to implement it as a system.

Even then, success will probably depend on putting good focus on the easy + high impact actions.

Sustainability will always be a hard metric to prioritize, especially if things like profit or growth take precedence in the long term.

It’s our job to find opportunities where we’re able to make that happen.

Change the status quo.

Helpful Resources used for research of this article:

I run the most entertaining front-end newsletter on the web!

“Exceptional Frontend” is for any devs out there that want a front-end centered newsletter that tries to be different from everybody else. Big focus was put into making it unique and most importantly — FUN!

While also at the same time helping devs become exceptional at what they do.

You can sign up here.

How To Measure Environmental Sustainability In Software Development