Skip to main content

Search...

Green Software: What If Planet Earth Were a Stakeholder?

Green software starts with one question: what if the earth were a stakeholder in your next sprint? Supporting old devices cuts e-waste and saves costs.

• • Updated: • 11 min read
Cover of the expert talk on 'Green Software: What If Planet Earth Were a Stakeholder?' with Jutta Eckstein and Richard Seidl.

Green software and sustainable software development cover two dimensions: environmental and social. On the environmental side, it is about the energy consumption of systems, choosing data centers that run on renewable energy and writing resource-efficient software that keeps hardware usable for longer. On the social side, it means planning for accessibility and inclusion from the outset instead of retrofitting them later.

Key Takeaways

  • E-waste is almost always caused by software: supporting older hardware in newer software versions extends the life of devices and directly reduces resource consumption.
  • Framing sustainability as a stakeholder question, “What would be different if the Earth were a stakeholder?”, gets a team thinking concretely right away, with no training needed up front.
  • Accessible systems become easier for everyone, because many limitations are temporary: noise, illness or outdated hardware affect far more people than those with permanent disabilities.
  • The Green Software Foundation and the free Digital Sustainability program of the United Nations give developers and testers a structured way into sustainable software development.

Sustainability in IT Has More Than One Dimension

Sustainable software development is about more than ecology. It has a social side, too. If you only think about energy consumption, you are missing half the story.

The social side covers accessibility, inclusion and how data is handled. On security, safety and privacy, the industry has come a long way. These topics were discussed for years without much happening. Today they are standard non-functional requirements, because the risk of ignoring them would be too high.

Jutta Eckstein takes hope from this for other sustainability topics. What worked for security and data protection can carry over to other fields. Environmental sustainability and the remaining social topics still have that same road ahead of them.

Why Software Excludes People without Meaning To

Software excludes people when it hard-codes assumptions about users that don’t hold for everyone. A binary input field can become a barrier.

Take body scanners at airports. The software expects a choice between male and female, and the scan runs differently depending on that choice. For transgender people, this doesn’t work, sometimes with traumatic consequences. In the end, it is the software that demands this zero-or-one logic. It could be built differently.

The teams that build such systems usually don’t act out of bad intent. They have a brief and they implement it. That’s exactly why it’s up to developers to question requirements like these.

The problem shows up in our own tools, too. In the OOP submission tool, the salutation field forced a rigid choice between Mr. and Ms. The question behind it: does the system even need that information? In this case, it didn’t. What isn’t collected can’t become a barrier.

Accessibility Makes Systems Better for Everyone

Building accessible software improves it for all users, not just a small group. That is the strongest argument against the idea that the effort isn’t worth it.

Accessibility often gets dismissed as an edge case: how many blind or deaf people use this system anyway? That math doesn’t hold up. A limitation doesn’t have to be permanent. An ear infection can make audio-based interaction harder for a while. A noisy environment creates the same problem in a given situation.

Once teams keep this whole range in mind, systems become easier to use across every kind of situation. A persona spectrum helps here, one that puts permanent, temporary and situational limitations side by side.

Part of the problem is who builds software. The field is heavily male-dominated. To reflect the diversity of society, teams have to work against that imbalance deliberately.

Regulation or Self-Interest?

For social topics, regulatory pressure has been the strongest lever so far. For environmental sustainability, self-interest might be enough.

Data protection shows the pattern. Before the GDPR, plenty of people complained, and some providers wanted to avoid Europe altogether or build separate websites. Today, compliance is routine. Accessibility is heading down the same path, driven by upcoming legal requirements. Some expect the EU AI Act to go the same way.

Environmental sustainability is a different case. Teams that take it seriously cut costs at almost every level and make their software faster. Everyone wins.

“Once you’ve internalized the principles and practices and simply do it because it pays off on so many levels, you may not need the legal lever at all.”

(Jutta Eckstein)

Even greenwashing can be read two ways. If companies feel they have to pretend, they have at least realized that something needs to happen. That can be a first step, in the spirit of fake it till you make it. The solution isn’t good yet, but something has shifted in people’s heads.

How to Bring Sustainability into Your Team

The simplest way in is one question: what if one of our stakeholders were the planet? That question gets people thinking immediately.

For some stories, it changes nothing. For others, it does. Suddenly the team wonders whether a feature could be built differently. Once the conversation has started, it often keeps going on its own. Awareness comes first; a lot of the rest can then be solved technically.

The Definition of Done is a natural next step. A team can add monitoring of energy consumption before the next release goes out. That way you at least know whether consumption is going up, staying flat or going down.

Sustainability works best as part of the culture from day one. Ask the question from the beginning and it becomes part of every decision, from choosing a cloud provider to how you write code. You can also bring it into a retrospective, with the planet as a stakeholder.

The Biggest Lever for Green Software Is Infrastructure and Architecture

Right now, the biggest savings come from fundamental infrastructure and architecture decisions, not from individual lines of code. Development contributes, but the big-ticket items come earlier.

One concrete lever is choosing the region for a data center. Google offers a region picker that shows how much of the energy at a location comes from renewable sources, in some cases up to one hundred percent. The choice then depends not only on availability and cost, but also on where the energy comes from.

The same principle applies to asynchronous jobs. A job that doesn’t have to run right away can start when renewable energy is available at the location where it runs, instead of at some arbitrary time.

In development itself, the old virtues help. Scarce memory and narrow bandwidth used to force lean systems. That same frugality is needed again, instead of assuming that hardware costs nothing.

Most E-Waste Is Caused by Software

Most electronic waste traces back to software, not to broken hardware. That puts a big lever in the industry’s hands.

When do you buy a new smartphone? Usually when the operating system is no longer supported, security problems appear or apps stop running. The hardware often still works. The software is what makes it unusable.

Software can also do the opposite and keep supporting older hardware for longer. One way to do this is sustainability toggles, a variant of the familiar feature toggles. If the system detects an old client that can’t handle a feature, that client gets a slimmed-down version or none at all. The system stays usable either way.

The difference is in the default. Instead of requiring every user to move to specific hardware, the software lets older devices keep running. That extends their useful life and cuts down on waste.

Do AI and Blockchain Really Need That Much Energy?

AI and blockchain use a lot of energy, but we can’t do without them if we want more sustainability at all. Climate models without AI are hard to imagine.

The question is less whether to use these technologies and more how to develop them. For large language models, the guiding principle is reduce, reuse. Models are built smaller and shared with others, so that not every team starts from scratch and multiplies the energy demand. The same goes for test data, which can also be resource-intensive.

With cryptocurrency mining, the problem is often the location. A large share happens in regions where energy comes mainly from coal. The same applies to any data center that runs mostly on fossil fuels. And that is a decision you can influence.

Where to Start Learning More

To get started, there are free courses and one simple question that needs no prior knowledge. Both work starting tomorrow.

The Green Software Foundation, a nonprofit started by a handful of companies and now more broadly supported, collects principles and patterns for developers. It offers a free Sustainability Practitioner course that helps put the topic in context.

The United Nations also runs a training program called Digital Sustainability. The course is still being built: four modules are planned, and two are available so far. You can find it on the UN Campus, also free of charge.

You don’t need any of that for the first step, though. It’s enough to ask in your next discussion what would be different if the Earth were a stakeholder. That question alone often sets a lot in motion.

Frequently Asked Questions

Is there more to sustainable software than just energy consumption?

Yes. In addition to the environmental aspects (such as energy consumption, the choice of data centers powered by renewable energy, and resource-efficient software), there is also a social dimension: accessibility, inclusion, and data handling. When it comes to security, safety, and privacy, the industry has already come a long way; in those areas, these points are considered non-functional requirements. For environmental issues and the other social topics, this journey still lies ahead.

Should a system even ask for information such as gender?

Only if it actually needs it. In the OOP submission tool, the title field required a rigid distinction between “Mr.” and “Ms.,” even though the system did not need that information. What is not collected cannot be a barrier. Body scanners at airports illustrate the flip side: there, a binary selection controls the scan and fails when used by transgender individuals.

Is accessibility worth the effort if only a few users are affected?

This line of reasoning falls short because limitations do not have to be permanent. An ear infection temporarily makes audio-based operation more difficult; a noisy environment does so situationally; and outdated hardware does as well. A spectrum of user personas that juxtaposes permanent, temporary, and situational limitations makes this range visible. Systems that take these into account become easier to use across all usage scenarios.

Does optimized code yield more benefits than changes to the infrastructure?

The greatest savings lie in fundamental infrastructure and architectural decisions, not in individual lines of code. One example is the choice of region for a data center: Google’s Region Picker shows the percentage of renewable energy at the location, in some cases up to one hundred percent. Asynchronous jobs can also be scheduled to run when renewable energy is available.

How does a team know if its software’s energy consumption is increasing?

Through monitoring that is incorporated into the Definition of Done, for example, before each release. This makes it clear whether consumption is increasing, remaining the same, or decreasing. Before that comes awareness: The question of what would be different if the planet were a stakeholder immediately sparks concrete considerations and can also be posed during a retrospective.

Why does working hardware end up as electronic waste?

Most often, it’s the software that’s the trigger, not a hardware defect. A smartphone is replaced when the operating system is no longer supported, security issues arise, or apps no longer run, even though the device is still technically functional. This gives development teams significant leverage: software that continues to support older devices extends their useful life.

What are Sustainability Toggles?

A variation of the well-known feature toggles that responds to the client’s capabilities. If the system detects an older client that cannot support a feature, that client receives a stripped-down version of the feature (or none at all) but remains usable. Instead of forcing all users to upgrade their hardware, the software allows older devices to continue functioning.

Where can developers and testers learn about sustainable software development?

The Green Software Foundation, a nonprofit, compiles principles and patterns and offers a free course to become a Sustainability Practitioner. The United Nations runs the Digital Sustainability program, also free of charge, through the UN Campus; two of its four planned modules are currently available. To get started, simply ask your team: What would be different if the Earth were a stakeholder?

Share this page