Principles for Sustainable Software Design

Home Back to SDIA Website

Principles of Sustainable Software Design

The principles capture the essence of the sustainability criteria for software engineering defined by the team at Umweltcampus Birkenfeld, the University of Zurich and the Oeko Institute as part of the Green Software Engineering research that was funded by the German Environmental Agency. Further we review & include the criteria defined by the German environmental label ‘Blue Angel’ (Resources and Energy-Efficient Software Products - DE-UZ 215)

Key considerations

Software applications & their supply chain

Information technology (IT) itself can be divided into the application (what the user is seeing) and the infrastructure that is required to deliver the application to the user.

IT applications have a supply chain, it’s what we call digital infrastructure in this document  and it encompasses both the physical infrastructure (data center, electricity, etc.) as well as the IT infrastructure (e.g. hardware, networking, and virtualization software). Together, this digital infrastructure generates digital resources, which are used to power the IT application and provide connectivity, enabling users to connect to an application.


Users can access an application using a device, e.g. a smartphone or computer with a browser.

The application requires digital resources to run. These resources are provisioned by digital infrastructure.

Digital infrastructure is the combination of IT hardware, networking, and a data center facility.

The main input in the supply chain is electricity. As digital infrastructure generates heat, we use the term energy to capture both. The main output are digital resources.

Who is responsible for using resources efficiently?

Source: Miro

Each participant in the value-creation process has responsibilities when it comes to the ‘greening’ of their part of the value chain as well as the sustainable consumption of inputs and outputs.

Consumer of digital applications & services, provides inputs & uses outputs
Practice sustainable & responsible consumption, e.g. turning off applications not in use, or deleting data not needed anymore
A user should turn off applications & functionalities that are not needed
Software Application
Turn user inputs into useful output, by utilizing digital resources & programming
Transparent resource consumption, minimizing resource use, use sustainable digital resources
A software developer should ensure that an application can be ‘switched-off’ when its not being used
Resource Provisioning
Allocating digital resources to applications
Allocating resources as efficiently as possible, recommendations on optimization towards application
A virtualization platform should re-allocate resources that are not being utilized
Digital Infrastructure
Producing digital resources for allocation towards applications
Producing digital resources that are sustainable
A data center should re-use generated heat or consume physical renewable energy sources

Participants who are active in any of these parts of the value chain can utilize the best practices below to improve the sustainability of their operations. Each measure has a direct impact on the environmental footprint of the organization.

‘Natural Resource’: In the context of this document we define a natural resource, as a raw material, a form of energy or the emission absorption capability of an environmental medium. We refer to it in the following best practices simply as ‘resources’. These are not to be confused with hardware resources.

One overarching principle: Minimize resource usage

When looking at the core philosophies defined by Eric Raymond for Unix, there is one principle that should be revised given our global, society challenge of limiting resource usage, carbon emissions and overall moving to sustainable consumption & production across all sectors.

Value developer time over machine time → Eric Raymond’s rules

Machine time, or as we consider them - digital resource primitives (compute, memory, storage, network) - are not infinite, as the term cloud computing might suggest. They are finite, and ties to physical consumption of natural resources - since the end of Moore’s Law - in an almost linear relationship. If an application consumes more digital resource primitives, it consumes more hardware resources and though that energy and natural resources.

In simpler terms: Every CPU cycle, every GB of memory, GB of storage and network has an impact on the environment.

Hence the overarching principle for every software developer, product manager, designer or architect should be to minimize resource use of an application.


Our recommendations are building on the existing studies referenced below. However we divide them into three groups:

  • Functional recommendations, such as the ability to turn off functionalities, for roles/stakeholders such as user interface designers, user experience teams, product management, business analysts, etc.
  • Architecture recommendations, such as designing a modular technical architecture, for software architects, technical management, etc.
  • Development recommendations, such as avoiding blocks on future resources, for software developers, site reliability engineers, and operational engineering teams.

With this separation we want to ensure that the recommendations are relevant for the different roles who are involved in the making of a Digital Product. If a person occupies multiple roles (e.g. in a small startup) where product management and architecture might be combined, you can freely combine them.

Further, we need to segment the recommendations for different types of software applications. The categories have been defined in previous studies. They are numbered and referenced in the headline of each recommendation:

  1. Local or client-side application (DE: lokale Anwendung)
  2. Client-side application with remote data storage (DE: Anwendung mit entfernter Datenhaltung)
  3. Client-side application with remote processing (DE: Anwendung mit entfernter Verarbeitung)
  4. Server-side application (DE: Serverdienst)

Lastly we have ordered the recommendations by importance.

Functional Recommendations

Define requirements to minimize the hardware requirements (1, 2, 3, 4)
Design the application so that the user has control and visibility over the resource-consumption from their usage (1, 2, 3, 4)
Ability for the user to turn off not-needed or unused functions of the software (1, 2, 3, 4)
Support delay tolerance and slow connectivity (2)
Support an offline version of the application (2, 3)
Ability to completely remove the application (1, 2, 3, 4)
Turn off features that are not supported on a older hardware (1, 2, 3, 4)
Delivery of the software only via internet (1, 2, 3, 4)
Consider removing outdated user data or suggest to the user to remove data (1, 2, 3, 4)
Consider monitoring feature creep (1, 2, 3, 4)

Architecture Recommendations

Micro-services that represent application functionalities & core features (4)
Consider web-based user-interfaces that are operating-system independent (1, 2, 3)
Before building native client-applications perform a proper analysis on performance & resource usage (1, 2, 3)
Consider decoupling frontend and backend
Consider delivering a static frontend to and to shift most of processing and storage to server-side micro-services (1, 2, 3)
Consider operating micro-services as function-like services that are switched off when not used (4)
Consider moving as many operations as possible into asynchronous background processes that can be delayed or moved (4)
Support incremental, over the air updates that do not replace the entire application on each update-cycle (1, 2, 3)
Support public APIs on all main functionalities for the programmatic use & as well as data export (2, 4)
Support data interoperability or export into common formats (2, 4)
Consider measuring the total resource use as part of your integration tests to provide insights for product management and development on areas of improvement (1, 2, 3, 4)

Development Recommendations

Remove unnecessary libraries and favor libraries that provide required only functionality needed (1, 2, 3, 4)
Minimize the hardware requirements for any client-side application (1, 2, 3)
Report the resource-usage of a single operation and make it visible to the client-side (1, 2, 3, 4).
Turn off staging & test environments (1, 2, 3, 4)
Don’t run builds on each minor code-change (1, 2, 3, 4)
Shift processing and storage to server-side if it helps reduce client-side obsoleteness (1, 2, 3, 4)
Ensure restart-ability, and up- and down-scaling (4)
Apply ‘mobile-first’ principle to ‘oldest machine first’ (1, 2, 3, 4)
Do not block resources that are not being used (1, 2, 3, 4)
Zero work should equal near-zero resource-use (except background processes) (1, 2, 3, 4)
Avoid code & software bloat (1, 2, 3, 4)
Consider minimalism as your development practice (1, 2, 3, 4)

Remaining questions

  • Should we actually still build native applications or do everything in the browser and rather assume better connectivity (so that resources can be used centrally and hence more efficiently)
  • Chrome vs. Native App - what’s the difference with the same scenario? Word vs. Google Docs
  • The studies before are mostly applicable for desktop software applications what about software-as-a-service?
  • Sustainability vs. resource efficiency (principles, e.g. open source vs. techniques)


Sustainable software products — Towards assessment criteria for resource and energy efficiency - Eva Kern, Lorenz M. Hilty, Achim Guldner, Yuliyan V. Maksimov, Andreas Filler , Jens Gröger, Stefan Naumann (https://doi.org/10.1016/j.future.2018.02.044)