Nachhaltige Softwareentwicklung: Neue Sicht auf alte NFRs

Nachhaltige Softwareentwicklung bedeutet, sowohl Energie und Hardware-Ressourcen effizient zu nutzen als auch Software langlebig und wartbar zu halten. Nachhaltigkeit ist dabei kein neues Qualitätskriterium, sondern eine zusätzliche Perspektive auf bestehende nicht-funktionale Anforderungen wie Performance, Wartbarkeit und Reliability. Auch der Testprozess selbst verbraucht Ressourcen, etwa durch Lastgeneratoren und Pipelines, und bietet konkretes Einsparpotenzial.

Das Wichtigste in Kürze

• Nachhaltigkeit in der Softwareentwicklung ist kein neues Qualitätskriterium, sondern eine neue Perspektive auf bereits vorhandene nicht-funktionale Anforderungen wie Performance, Wartbarkeit und Reliability.
• Langlebige, wartbare Software ist nachhaltiger als häufig neu geschriebene, weil jeder Neustart Ressourcen und Entwicklerzeit verbrennt und historisch gewachsene Systeme enormes Einsparpotenzial verstecken.
• Wer Performance-Tests auf Zeitfenster mit hohem Anteil erneuerbarer Energie verschiebt, nutzt Energie, die sonst verworfen wird, ohne Mehrkosten beim Cloud-Provider zu verursachen.
• Unnötiger Netzwerktraffic in Pipelines und Staging-Systemen erzeugt messbaren CO₂-Ausstoß: eine falsch gebaute Pipeline kann einem Äquivalent von 600 gefahrenen Kilometern entsprechen, eine optimierte nur 600 Metern.
• Wo Nachhaltigkeit als Argument nicht zieht, lässt sie sich über Kosten einführen, weil reduzierter Cloud-Traffic und effizientere Ressourcennutzung direkt die Rechnung senken.

Nachhaltige Softwareentwicklung: kein neues Qualitätsmerkmal, sondern eine neue Brille auf bekannte NFRs

Nachhaltigkeit in der Softwareentwicklung lässt sich nicht als isoliertes nicht-funktionales Requirement behandeln. Sie ist eine zusätzliche Perspektive auf NFRs, die ohnehin schon im Projekt stehen: Performance, Wartbarkeit, Reliability, Security. Markus Lachenmayr formuliert es so, dass Nachhaltigkeit kein neues NFR sei, sondern eine neue Sicht auf vorhandene.

Der Begriff trägt einen falschen Beiklang. Es geht nicht um Aktivismus, sondern um den Umgang mit Ressourcen: Hardware, Energie und der dabei freigesetzte Kohlenstoff. Dazu kommt ein Aspekt, der in vielen Nachhaltigkeitsinitiativen untergeht: die Langlebigkeit der Software selbst.

Wer alle zwei oder drei Jahre von vorn anfängt, verbrennt Ressourcen und Menschen. Software, die nicht mehr wartbar ist, landet in der Tonne, und das Team startet bei null. Genau das gilt es zu vermeiden.

Warum Nachhaltigkeit ins Requirements Engineering gehört

Kein Qualitätsattribut lässt sich am Ende des Entwicklungszyklus noch hineintesten. Das funktioniert nicht bei Performance, nicht bei Wartbarkeit und nicht bei Nachhaltigkeit. Wer Nachhaltigkeit will, muss früh in die Anforderungsphase.

Tester sind es gewohnt, die unliebsamen Themen aufzutreiben, die gern vergessen werden. Nachhaltigkeit gehört aktuell dazu. Florian Krautwurm plädiert dafür, dass Tester von vornherein in die Requirements-Phase gehen und die Nachhaltigkeitsbrille in die Trade-off-Analyse mit den bestehenden NFRs einbringen.

Der Punkt ist nicht, dass Nachhaltigkeit aktiv abgelehnt wird. Sie wird schlicht übersehen. In der Architektur wird auf die wichtigen NFRs geachtet, das Nachhaltigkeitsthema fällt unbewusst hinten runter.

Performance, Wartbarkeit, Security: wo Nachhaltigkeit zieht und wo sie kollidiert

Nachhaltigkeit verhält sich zu anderen NFRs als Plus-Minus-Rechnung, nicht als Selbstläufer. Manche Qualitätsmerkmale zahlen positiv ein, andere arbeiten dagegen. Diese Trade-offs muss man explizit machen.

Performance und Effizienz sind der naheliegende Hebel. Du kannst Software schnell machen, indem du sie effizient baust, was früh Designentscheidungen verlangt. Oder du merkst beim Deployment, dass es langsam läuft, und drehst einfach den Ressourcenhahn auf. Das ist die nicht nachhaltige Variante.

Wartbarkeit wirkt fast durchgängig positiv auf Nachhaltigkeit. Security dagegen kollidiert oft: Verschlüsselung und Entschlüsselung brauchen mehr Rechenleistung. Die Antwort ist nicht, Security wegzuwerfen, sondern zu fragen, wie weit die Maßnahmen gehen müssen und wo Abstriche vertretbar sind. Personenbezogene Daten sicher zu halten, ist selbst Teil sozialer Nachhaltigkeit.

Auch Reliability lässt sich hinterfragen. Bei Safety-relevanten Systemen ist Verfügbarkeit nicht verhandelbar. Aber muss ein About-Menü wirklich mit fünf Neunen Verfügbarkeit laufen, oder darf es da auch mal einen Ausfall geben?

Die folgende Übersicht fasst die Trade-off-Richtungen zusammen, die im Projekt diskutiert wurden:

Langlebige Software spart Hardware, nicht nur Code

Wartbarkeit und Austauschbarkeit sind direkte Nachhaltigkeitshebel. Software, die alle drei Jahre neu geschrieben wird, verheizt Menschen und Ressourcen. Software, die auch auf älterer Hardware weiterläuft, verlängert deren Lebensdauer.

Hier kommt der Begriff Embodied Carbon ins Spiel: der Kohlenstoff, der bei Herstellung, Recycling und Zerstörung von Hardware frei wird. Je länger deine Software auf älterer Hardware läuft, desto besser fällt diese Bilanz aus. Abwärtskompatibilität betrifft also nicht nur frühere Softwareversionen, sondern auch alte Hardware.

Austauschbarkeit zahlt langfristig ein. Wenn es in einigen Jahren eine ressourcensparendere Variante eines Algorithmus gibt, musst du sie einbauen können. In einem Monolithen ist das schwierig, modulare und containerisierte Strukturen machen es möglich.

Wie sich Nachhaltigkeit in Code Reviews verankern lässt

Nachhaltigkeit gehört in die Implementierung, nicht nur ins Design. Eine schlecht implementierte Schleife oder fehlendes Caching zerstören die Effizienz auf einer Ebene, die kein Architekturdiagramm abbildet. Deshalb braucht es Code Reviews, die nicht nur auf Bugs schauen, sondern auf die Art der Umsetzung.

Wichtig ist die Verhältnismäßigkeit. Es geht nicht darum, einem Entwickler vier eingesparte Bytes vorzurechnen. Der Fokus liegt auf den Knackpunkten: Stellen, die millionenfach durchlaufen werden. Dort wirkt sich eine Optimierung auf den Kurvenverlauf aus, bei Einzelfällen rechnet sich der Aufwand nicht.

Damit das Team mitzieht, braucht jede Anmerkung eine Begründung. Reines Anweisen funktioniert nicht. Methodisch unterscheidet sich ein Nachhaltigkeits-Review nicht von einem Secure-Coding-Review: ein weiterer Aspekt, den man mitbringt und dessen Sinn man vermitteln muss.

Es hilft nichts, laut zu schauen und zu sagen, mach das anders. Man muss die Begründung dazu geben und es den Leuten beibringen. Effizient programmieren sollte man ohnehin, aus anderen Gesichtspunkten. (Markus Lachenmayr)

Welche Werkzeuge messbar machen, was nachhaltig ist

Für Nachhaltigkeit gibt es selten einen Unit-Test, der ein klares Ergebnis liefert. Vieles läuft über Monitoring statt über Testfälle. Große Cloud-Provider wie AWS, Azure und Google Cloud bieten eigene Dashboards, die den Carbon Footprint sichtbar machen.

Ein greifbares KPI ist die tatsächliche Auslastung der bezogenen Ressourcen. Liegt sie im einstelligen Prozentbereich, hältst du wahrscheinlich zu viel Kapazität vor und hast Optimierungspotenzial.

Für Wartbarkeit helfen statische Code-Analysen mit Metriken wie technischer Schuld, Fan-In und Fan-Out. Sie liefern keine absolute Wahrheit, aber einen Anhaltspunkt, ob du dich verschlechterst oder verbesserst, und machen den Zustand quantifizierbar. Für Web-UI-Effizienz gibt es Analyzer, die Hotspots high-level anzeigen. Die eigentliche Arbeit danach bleibt manuell.

Ein offener Ansatz: ein Custom-Ruleset für die statische Code-Analyse, dessen Regeln gezielt auf Nachhaltigkeit getaggt sind. Umgesetzt wurde das nicht, als Idee trägt es.

Nachhaltig testen schlägt Nachhaltigkeit testen

Der größere Hebel liegt nicht darin, Nachhaltigkeit zu testen, sondern nachhaltig zu testen. Testinfrastrukturen sind oft groß und verbrauchen entsprechend viel. Performance-Tests skalieren Lastgeneratoren und das System under Test hoch, Pipelines schieben Datenmengen hin und her.

Viele Testaufgaben sind nicht zeitgebunden. Nicht jeder Test muss nach jedem Commit laufen. Performance-Tests laufen ohnehin oft nachts, könnten aber genauso mittags laufen, wenn gerade viel erneuerbare Energie im Netz ist.

Dafür gibt es API-Calls für nahezu jedes Land, die zwei Dinge liefern: die aktuelle Zusammensetzung des Stroms und den Demand. Findest du ein Fenster mit hohem Anteil erneuerbarer Energie und niedriger Nachfrage, kannst du rechenintensive Tests genau dorthin schieben. Du sparst damit keinen Cent, der Cloud-Provider rechnet trotzdem ab. Aber die eingesparte grüne Energie steht anderswo zur Verfügung.

Was falsch gebautes Staging kostet: 600 Kilometer gegen 600 Meter

Testdaten und Staging-Systeme erzeugen massiven Netzwerkverkehr, und der lässt sich in Kohlenstoff umrechnen. Container werden lokal in die Cloud und wieder zurück geschoben. Dieser Traffic schlägt deutlich zu Buche.

Florian nennt eine Rechnung aus einem viel diskutierten Shift-Report: Eine falsch gebaute Pipeline samt Staging kann dem Äquivalent von 600 gefahrenen Autokilometern entsprechen. Baut man dieselbe Pipeline um, landet man bei 600 Metern.

Die Zahlen sind grobe Annäherungen, abhängig von Distanz, Caching und weiteren Faktoren. Trotzdem öffnen sie die Augen, weil über diesen Verbrauch normalerweise niemand nachdenkt. In der Softwareentwicklung diffundiert der Ressourcenverbrauch weg, alles ist scheinbar einfach da. Erst die Umrechnung in Autokilometer macht ihn greifbar.

Traffic, der nicht in die Cloud wandert, kostet auch nichts. An dieser Stelle treffen sich Nachhaltigkeit und Kosten, was die Argumentation gegenüber dem Management erleichtert.

Die Cloud hat das Bit-Drehen abgeschafft und einen Schuldenberg hinterlassen

In den Anfangszeiten der Cloud verschob sich das Denken. Niemand musste mehr jedes Bit umdrehen, damit es irgendwo hineinpasst, weil sich Ressourcen einfach hochskalieren ließen. Genau in dieser Phase sind viele Projekte entstanden, die deutlich zu viele Ressourcen verbrauchen.

Diese Projekte laufen oft bis heute, teilweise containerisiert, aber nach demselben Muster: Cloud hochskalieren, fertig. Das größte ungehobene Potenzial liegt deshalb in Software, die historisch gewachsen ist.

Anforderungen ändern sich laufend, die Architektur zieht selten nach. Ein lohnender Review-Ansatz: zwei, drei Schritte zurückgehen, die heutigen Requirements gegen den Ist-Stand halten und fragen, ob du den Kern des Systems mit heutigem Wissen anders schreiben würdest.

Re-Architecting gehört dazu. Stellst du nach Jahren fest, dass sich ein Algorithmus deutlich ressourcensparender umsetzen lässt, solltest du das angehen können. Das setzt voraus, dass die Architektur von Anfang an dafür ausgelegt war. Ein Trade-off bleibt: Manche Alt-Software läuft gerade deshalb sparsam, weil die Hardware knapp war. Ein Neubau auf moderner Plattform kann mehr verbrauchen. Die Abwägung muss man bewusst treffen.

Wie du anfängst, wenn Nachhaltigkeit im Projekt kein Thema ist

Der erste Schritt ist Wissen, nicht ein Tool. Organisationen wie Principles.Green und die Green Software Foundation haben deutlich mehr Zeit und Aufwand in das Thema gesteckt und bieten Tutorials, Artikel und konkrete Patterns für nachhaltige Software. Sich dieses Wissen anzueignen und im Hinterkopf zu behalten, ist bereits wertvoll.

Bei Designentscheidungen ziehst du dieses Wissen dann heran und schlägst nachhaltigere Varianten vor. Das ist der Punkt, an dem aus Lektüre Praxis wird.

Entscheidend für den Start ist stakeholdergerechte Sprache. Legt eine Firma keinen Wert auf Nachhaltigkeit, mappst du das Thema auf Faktoren, die zählen. Kosten passen fast immer gut dagegen, besonders in der Cloud, wo Energie und Datenübertragung direkt Geld kosten.

Du startest also über das Argument, das beim jeweiligen Stakeholder zieht, und ergänzt den Nachhaltigkeitsaspekt im Nachgang. Das Management sieht gern, wenn Verbrauch gemessen und kleingehalten wird. Über diesen Hebel bringst du Nachhaltigkeit von Beginn an ins Projekt.

Häufig gestellte Fragen

Lohnt es sich, Nachhaltigkeit als eigenes nicht-funktionales Requirement zu formulieren?

Nein. Nachhaltigkeit funktioniert nicht als isoliertes Requirement, sondern als zusätzliche Sicht auf NFRs, die ohnehin im Projekt stehen: Performance, Wartbarkeit, Reliability, Security. Sinnvoll ist es, diese Brille in die Trade-off-Analyse einzubringen. Das Thema wird selten aktiv abgelehnt, es fällt in der Architekturarbeit unbewusst hinten runter, weil andere NFRs lauter sind.

Kann man Nachhaltigkeit am Ende der Entwicklung noch hineintesten?

Nein. Kein Qualitätsattribut lässt sich am Ende des Entwicklungszyklus nachträglich hineintesten, weder Performance noch Wartbarkeit noch Nachhaltigkeit. Wer Effizienz will, muss in die Anforderungsphase. Tester sind es gewohnt, unliebsame und gern vergessene Themen aufzutreiben, und können diese Rolle auch hier übernehmen, indem sie früh mit am Tisch sitzen.

Steht Security der Nachhaltigkeit im Weg?

Security zahlt tendenziell negativ auf Nachhaltigkeit ein, weil Verschlüsselung und Entschlüsselung Rechenleistung kosten. Die Konsequenz ist Abwägen, nicht Streichen: Wie weit müssen die Maßnahmen gehen, wo sind Abstriche vertretbar? Personenbezogene Daten sicher zu halten, ist selbst Teil sozialer Nachhaltigkeit. Wartbarkeit dagegen wirkt fast durchgängig positiv.

Warum ist langlebige Software besser für die Hardware-Bilanz?

Weil Embodied Carbon zählt: der Kohlenstoff, der bei Herstellung, Recycling und Zerstörung von Hardware frei wird. Je länger eine Anwendung auf älterer Hardware läuft, desto besser fällt die Bilanz aus. Abwärtskompatibilität betrifft deshalb nicht nur frühere Softwareversionen. Wird eine Anwendung alle zwei bis drei Jahre neu geschrieben, verbrennt jeder Neustart Ressourcen und Entwicklerzeit.

Worauf sollte ein Code Review achten, wenn es um Ressourcenverbrauch geht?

Auf die Knackpunkte, also Stellen, die millionenfach durchlaufen werden. Dort verändert eine Optimierung den Kurvenverlauf, bei Einzelfällen rechnet sich der Aufwand nicht. Vier eingesparte Bytes vorzurechnen, bringt nichts. Typische Kandidaten sind schlecht implementierte Schleifen und fehlendes Caching. Jede Anmerkung braucht eine Begründung, sonst zieht das Team nicht mit.

Bringt es etwas, rechenintensive Tests nach dem Strommix zu planen?

Ja, weil viele Testaufgaben nicht zeitgebunden sind. Für nahezu jedes Land gibt es API-Calls, die die aktuelle Zusammensetzung des Stroms und die Nachfrage liefern. Findet man ein Fenster mit hohem Anteil erneuerbarer Energie und niedriger Nachfrage, lassen sich Performance-Tests dorthin verschieben. Gespart wird dabei kein Geld, der Cloud-Provider rechnet trotzdem ab.

Wie stark schlagen Test-Pipelines und Staging-Systeme beim CO₂-Ausstoß zu Buche?

Deutlich. Eine falsch gebaute Pipeline samt Staging kann dem Äquivalent von 600 gefahrenen Autokilometern entsprechen, dieselbe Pipeline umgebaut nur 600 Metern. Die Zahlen sind grobe Annäherungen und hängen von Distanz, Caching und weiteren Faktoren ab. Ursache ist Traffic: Container werden lokal in die Cloud und wieder zurück geschoben.

Welches Argument zieht bei Stakeholdern, denen Nachhaltigkeit nichts bedeutet?

Kosten. In der Cloud kosten Energie und Datenübertragung direkt Geld, deshalb senkt Traffic, der nicht in die Cloud wandert, die Rechnung. Das Management sieht gern, wenn Verbrauch gemessen und kleingehalten wird. Ein greifbares KPI ist die Auslastung der bezogenen Ressourcen: liegt sie im einstelligen Prozentbereich, wird zu viel Kapazität vorgehalten.