Sustainable software development means using energy and hardware resources efficiently as well as keeping software durable and maintainable. Sustainability is not a new quality criterion, but an additional perspective on existing non-functional requirements such as performance, maintainability and reliability. The test process itself also consumes resources, for example through load generators and pipelines, and offers concrete savings potential.
Key Takeaways
- Sustainability in software development is not a new quality criterion, but a new perspective on existing non-functional requirements such as performance, maintainability and reliability.
- Long-lasting, maintainable software is more sustainable than frequently rewritten software, because every restart burns resources and developer time and historically grown systems hide enormous savings potential.
- Shifting performance tests to time windows with a high proportion of renewable energy uses energy that would otherwise be discarded without incurring additional costs for the cloud provider.
- Unnecessary network traffic in pipelines and staging systems generates measurable CO₂ emissions: an incorrectly built pipeline can be the equivalent of 600 kilometers driven, an optimized one only 600 meters.
- Where sustainability does not work as an argument, it can be introduced via costs, because reduced cloud traffic and more efficient resource utilization directly reduce the bill.
Sustainability is not a new quality characteristic, but a new set of glasses on familiar
Sustainability in software development cannot be treated as an isolated non-functional requirement. It is an additional perspective on NFRs that are already part of the project: Performance, Maintainability, Reliability, Security. As Markus Lachenmayr puts it, sustainability is not a new NFR, but a new perspective on existing ones.
The term has the wrong connotations. It is not about activism, but about the use of resources: hardware, energy and the carbon released in the process. There is also an aspect that is overlooked in many sustainability initiatives: the longevity of the software itself.
Starting from scratch every two or three years burns resources and people. Software that is no longer maintainable ends up in the garbage can and the team starts from scratch. This is exactly what needs to be avoided.
Why sustainability belongs in requirements engineering
No quality attribute can be tested at the end of the development cycle. This does not work for performance, maintainability or sustainability. If you want sustainability, you have to start early in the requirements phase.
Testers are used to finding the unpleasant topics that are often forgotten. Sustainability is currently one of them. Florian Krautwurm argues that testers should enter the requirements phase from the outset and incorporate sustainability into the trade-off analysis with the existing NFRs.
The point is not that sustainability is actively rejected. It is simply overlooked. In architecture, attention is paid to the important NFRs and the sustainability issue is unconsciously neglected.
Performance, maintainability, security: where sustainability pulls and where it collides
Sustainability relates to other NFRs as a plus/minus calculation, not as a self-runner. Some quality characteristics contribute positively, others work against them. These trade-offs must be made explicit.
Performance and efficiency are the obvious levers. You can make software fast by building it efficiently, which requires early design decisions. Or you can realize during deployment that it is running slowly and simply turn off the resource tap. This is the unsustainable option.
Maintainability almost always has a positive effect on sustainability. Security, on the other hand, often clashes: encryption and decryption require more computing power. The answer is not to throw away security, but to ask how far the measures need to go and where compromises are justifiable. Keeping personal data secure is itself part of social sustainability.
Reliability can also be questioned. Availability is non-negotiable for safety-relevant systems. But does an About menu really have to run with five nines availability, or can there sometimes be a failure?
The following overview summarizes the trade-off directions that were discussed in the project:
| NFR | impact on sustainability | consistency |
|---|---|---|
| Performance / Efficiency | positive, if efficiently designed at an early stage | prioritize design decisions, do not delay resources |
| Maintainability | strongly positive | Longevity reduces new construction and resource consumption |
| Security | tends to be negative | weigh up measures, do not cancel |
| Reliability / availability | context-dependent | question non-critical availability requirements |
Long-lasting software saves hardware, not just code
Maintainability and replaceability are direct sustainability levers. Software that is rewritten every three years burns up people and resources. Software that continues to run on older hardware extends its service life.
This is where the term embodied carbon comes into play: the carbon that is released during the production, recycling and destruction of hardware. The longer your software runs on older hardware, the better the carbon footprint. Backwards compatibility therefore not only applies to earlier software versions, but also to old hardware.
Replaceability pays off in the long term. If there is a more resource-efficient version of an algorithm in a few years’ time, you need to be able to install it. This is difficult in a monolith, but modular and containerized structures make it possible.
How sustainability can be anchored in code reviews
Sustainability belongs in the implementation, not just in the design. A poorly implemented loop or missing caching destroys efficiency at a level that is not represented by an architecture diagram. That’s why we need code reviews that not only look at bugs, but also at the way they are implemented.
Proportionality is important. It’s not about calculating four bytes saved for a developer. The focus is on the sticking points: Points that are passed through millions of times. This is where optimization has an effect on the curve; in individual cases, the effort does not pay off.
In order for the team to follow suit, every comment needs a justification. Simply giving instructions does not work. Methodologically, a sustainability review is no different from a secure coding review: another aspect that you need to bring to the table and make sense of.
It doesn’t help to look out loud and say, do it differently. You have to justify it and teach people how to do it. You should program efficiently anyway, from other points of view.
- Markus Lachenmayr
Which tools make it possible to measure what is sustainable
There is rarely a unit test for sustainability that delivers a clear result. Much is done via monitoring instead of test cases. Large cloud providers such as AWS, Azure and Google Cloud offer their own dashboards that make the carbon footprint visible.
One tangible KPI is the actual utilization of the resources used. If it is in the single-digit percentage range, you are probably holding too much capacity and have potential for optimization.
For maintainability, static analyses of code with metrics such as technical debt, fan-in and fan-out help. They do not provide an absolute truth, but they do give you an indication of whether you are getting worse or better and make the status quantifiable. For web UI efficiency, there are analyzers that show high-level hotspots. The actual work afterwards remains manual.
An open approach: a custom ruleset for static analysis whose rules are specifically tagged for sustainability. This has not been implemented, but the idea is there.
Sustainable testing beats sustainability testing
The bigger leverage lies not in testing sustainability, but in testing sustainably. Test infrastructures are often large and consume a lot of resources. Performance tests scale up load generators and the system under test, pipelines push data volumes back and forth.
Many test tasks are not time-bound. Not every test has to run after every commit. Performance tests often run at night anyway, but could just as easily run at midday when there is a lot of renewable energy in the grid.
There are API calls for almost every country that provide two things: the current composition of the electricity and the demand. If you find a window with a high proportion of renewable energy and low demand, you can push computationally intensive tests right there. You won’t save a penny, the cloud provider will still charge you. But the green energy saved is available elsewhere.
The cost of incorrectly built staging: 600 kilometers versus 600 meters
Test data and staging systems generate massive network traffic, and this can be converted into carbon. Containers are moved locally to the cloud and back again. This traffic has a significant impact.
Florian cites a calculation from a much-discussed Shift report: one incorrectly built pipeline including staging can be the equivalent of 600 kilometers driven by car. If you rebuild the same pipeline, you end up with 600 meters.
The figures are rough approximations, depending on distance, caching and other factors. Nevertheless, they are eye-opening because nobody normally thinks about this consumption. In software development, the consumption of resources diffuses away, everything is apparently just there. Only the conversion into car kilometers makes it tangible.
Traffic that doesn’t go into the cloud doesn’t cost anything. This is where sustainability and costs meet, which makes it easier to argue with management.
The cloud has done away with bit spinning and left behind a mountain of debt
In the early days of the cloud, there was a shift in thinking. Nobody had to flip every bit to make it fit somewhere because resources could simply be scaled up. It was precisely during this phase that many projects emerged that consumed far too many resources.
These projects are often still running today, sometimes containerized, but following the same pattern: scale up the cloud, done. The greatest untapped potential therefore lies in software that has grown historically.
Requirements are constantly changing and the architecture rarely follows suit. A worthwhile review approach: take two or three steps back, compare today’s requirements with the current status and ask whether you would write the core of the system differently with today’s knowledge.
Re-architecting is part of this. If you realize years later that an algorithm can be implemented in a much more resource-efficient way, you should be able to address this. This assumes that the architecture was designed for this from the outset. One trade-off remains: Some legacy software runs economically precisely because the hardware was scarce. A new build on a modern platform can consume more. The trade-off has to be made consciously.
How to get started if sustainability is not an issue in the project
The first step is knowledge, not a tool. Organizations such as Principles.Green and the Green Software Foundation have put significantly more time and effort into the topic and offer tutorials, articles and concrete patterns for sustainable software. Acquiring this knowledge and keeping it in mind is already valuable.
When making design decisions, you then draw on this knowledge and suggest more sustainable variants. This is the point at which reading becomes practice.
Stakeholder-oriented language is crucial for the start. If a company does not value sustainability, you map the topic to factors that count. Costs almost always go well against this, especially in the cloud, where energy and data transfer cost money directly.
So you start with the argument that resonates with the respective stakeholder and add the sustainability aspect afterwards. Management likes to see consumption being measured and kept to a minimum. You use this lever to introduce sustainability into the project right from the start.
