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

• Unix philosophy or here
• Minimalism in computing
• Code bloating
• Software bloating
• Feature creep

Software applications & their supply chain

Who is responsible for using resources efficiently?

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.

Recommendations

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)

References

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)