Planet Earth as a stakeholder

Sustainability in software development encompasses two dimensions: environmental and social. Ecologically, it is about the energy consumption of systems, the choice of data centers with renewable energy and resource-saving software that keeps hardware usable for longer. Socially, it means actively planning for accessibility and inclusion instead of making adjustments afterwards.

Key Takeaways

• E-waste is almost always generated by software: supporting old hardware with newer software versions extends the service life of devices and thus directly reduces resource consumption.
• Formulating sustainability as a stakeholder question, “What would be different if the earth were a stakeholder?”, immediately generates concrete considerations in the team without the need for prior training.
• Accessible systems become easier for all users because many restrictions are temporary: Noise, illness or outdated hardware affect significantly more people than just permanently affected groups.
• The Green Software Foundation and the United Nations Digital Sustainability Program, which is accessible free of charge, offer developers and testers a structured introduction to sustainable software development.

Sustainability in IT has more than one dimension

Sustainability in software development encompasses not only ecology, but also social aspects. If you only think about energy consumption, you are missing half the story.

The social side concerns issues such as accessibility, inclusion and the handling of data. The industry is now quite advanced when it comes to security, safety and privacy. These topics were discussed for a long time without much happening. Today, they are standard as non-functional requirements because the risk would otherwise be too high.

Jutta Eckstein draws hope from this for other sustainability issues. What has worked for security and data privacy can be transferred to other fields. The same path still lies ahead for ecological and other social sustainability.

Why does software unintentionally exclude people?

Software excludes people when it hard-codes assumptions about users that do not apply to everyone. A binary input field can become a barrier.

One example is body scanners at airports. The software expects a selection between male and female, and the scan is carried out differently depending on the selection. This does not work for transgender people, with sometimes traumatic consequences. Ultimately, it is the software that requires this zero-or-one logic. It could also be built differently.

The teams that develop such systems usually don’t act with malicious intent. They have a mission and implement it. This is precisely why it is up to the developers to question such specifications.

The problem also lies in their own tools. In the OOP submission tool, it was noticeable that the salutation required a rigid distinction between Mr. and Mrs. The question behind this: Does the system need this information at all? Not in this case. What is not needed cannot be a barrier.

Accessibility makes systems better for everyone

Building accessible software improves it for all users, not just a small group. This is the strongest argument against the assumption that the effort is not worth it.

Accessibility is often dismissed as a special case: how many blind or deaf people already use the system? This calculation falls short. A restriction does not have to be permanent. An ear infection can make it temporarily difficult to use audio. A noisy environment creates the same problem depending on the situation.

As soon as teams take this range into account, systems become easier to operate across all usage situations. A persona spectrum that juxtaposes permanent, temporary and situational restrictions is helpful here.

Part of the problem lies in the composition of the teams. Software is heavily male-dominated. In order to reflect social diversity, this imbalance must be consciously countered.

Do we need regulation or is self-interest enough?

So far, regulatory pressure has been the strongest lever for social issues. When it comes to environmental sustainability, self-interest could be enough.

Data privacy shows the pattern. Before the GDPR, many cursed, individual providers preferred to avoid Europe or build separate websites. Today, implementation is commonplace. The same trend is emerging for accessibility, driven by the upcoming obligation. Some expect the EU AI Act to follow the same path.

The case is different for environmental sustainability. Those who are concerned with it save costs at almost all levels and make the software more performant. That’s a win-win.

Once you have internalized the principles and practices and simply do it because it is positive on many levels, you may not even need the legal lever.

Jutta Eckstein

Even greenwashing can be read ambivalently. If companies have to pretend, they have at least recognized that something has to happen. This can be a first step, in the sense of fake it till you make it. The solution is not yet good, but something has changed in people’s minds.

How do you bring sustainability into the team?

The easiest way to start is to ask: What if one of our stakeholders was the planet? This question immediately gets people thinking.

For some stories, the question doesn’t change anything, for others it does. Suddenly the team considers whether a function could be implemented differently. Once the conversation has been initiated, it often takes on a life of its own. It’s all about awareness first, and many things can then be solved technically.

The next step is the definition of done. A team can start monitoring energy consumption before the next release goes out. This way, you at least know whether consumption is increasing, remaining the same or decreasing.

Sustainability as a culture is most effective right from the start. Asking the question from the outset anchors it in every decision, from cloud selection to development style. The question can also be asked in retrospective, with the planet as a stakeholder.

The greatest leverage lies in infrastructure and architecture

Currently, the biggest savings are in fundamental infrastructure and architecture decisions, not in individual lines of code. Development contributes, but the major construction sites lie ahead.

One concrete lever is the choice of region for a data center. Google offers a region picker that shows how high the proportion of renewable energy is at a location, in some cases up to one hundred percent. The selection is then based not only on availability and costs, but also on the energy source.

The same principle applies to asynchronous jobs. A job that does not have to run immediately can start when renewable energy is available at the execution location instead of at any time.

The old virtues help in development. In the past, scarce memory and narrow bandwidth forced economical systems. It is precisely this frugality that is in demand again, instead of assuming that hardware costs nothing.

Electronic waste is almost always caused by software

Most e-waste is caused by software, not defective hardware. This gives the industry a great deal of leverage.

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

Software can do the opposite and support older hardware for longer. Sustainability toggles, a variant of the familiar feature toggles, are one way of doing this. If the system detects an old client that cannot support a function, it is given a slimmed-down version or the function is not used at all. The system still remains usable.

The difference lies in the default. Instead of demanding that all users switch to certain hardware, the software allows old devices to continue running. This extends usability and reduces scrap.

Do AI and blockchain need so much energy?

AI and blockchain consume a lot of energy, but they are essential for achieving greater sustainability. Climate models without AI are hardly conceivable.

The question is not so much whether to use these technologies, but how to develop them. With large language models, the guiding principle is Reduce, Reuse. Models are built smaller and made available to others so that not every team starts from scratch and multiplies the energy requirements. The same applies to test data, which can also be resource-intensive.

When mining cryptocurrencies, the problem often lies in the location. Much of it takes place in regions where the energy comes mainly from coal. The same applies to any data center that is primarily powered by fossil fuels. This decision can be influenced.

Where you can start to learn more

To get started, there are free courses and a simple question that requires no prior knowledge. Both work from tomorrow.

The Green Software Foundation, a non-profit that was started by a few companies and is now more broadly based, collects principles and patterns for developers. It offers a free Sustainability Practitioner course to help classify the topic.

The United Nations also offers a training program called Digital Sustainability. The course is currently being developed and four modules are planned, two of which are currently available. It can be found on the UN Campus, also free of charge.

You don’t even need to take the first step. It is enough to ask in the next discussion what would be different if the Earth were a stakeholder. This question alone often triggers a lot.